@backblaze-labs/b2-sdk - v0.4.0
    Preparing search index...

    Interface B2SimulatorOptions

    Options for constructing a B2Simulator.

    interface B2SimulatorOptions {
        authTokenTtlMs?: number;
        customUploadTimestampsEnabled?: boolean;
        minimumPartSize?: number;
        onHookError?: (
            event: { error: Error; kind: "webhook" | "replication" },
        ) => void;
        onReplicate?: (
            event: {
                destinationBucketId: string;
                sourceBucketId: string;
                sourceFileVersion: FileVersion;
            },
        ) => void
        | Promise<void>;
        onWebhookDeliver?: (
            event: {
                bucketId: string;
                fileVersion: FileVersion;
                rule: EventNotificationRule;
            },
        ) => void
        | Promise<void>;
        partnerAccountHasValidPhone?: boolean;
        partnerAccountInGoodStanding?: boolean;
        partnerApiEnabled?: boolean;
        partnerAuthorize?: boolean;
        partnerBackupCapabilities?: readonly "all"[];
        partnerGroupsCapabilities?: readonly "all"[];
        recommendedPartSize?: number;
        strictAuth?: boolean;
    }
    Index
    authTokenTtlMs?: number

    How long auth tokens issued via b2_authorize_account are valid for, in milliseconds. The simulator also uses this TTL for upload authorization tokens issued via b2_get_upload_url and b2_get_upload_part_url. Defaults to 24 hours (real B2). Tests that want to exercise the 401/reauth retry path or stale upload URL handling can lower this and use B2Simulator.advanceTime to move simulator time past account-token expiry. Upload tokens are rejected at the exact expiry boundary.

    customUploadTimestampsEnabled?: boolean

    Whether the simulated account may set custom upload timestamps on b2_upload_file and b2_start_large_file. Defaults to false, matching production accounts without the restricted feature enabled.

    minimumPartSize?: number

    The minimum part size the simulator advertises in b2_authorize_account responses (apiInfo.storageApi.absoluteMinimumPartSize). Defaults to 5_000_000 to mirror production B2. Lower this in tests that exercise multipart control-flow branches but don't need realistic part sizes, because v8 coverage instrumentation pushes 5 MB+ part hashing past 60 s on the slowest CI runners, which trips vitest's IPC RPC timeout.

    onHookError?: (event: { error: Error; kind: "webhook" | "replication" }) => void

    Diagnostic hook: invoked with any error thrown or rejected by onWebhookDeliver / onReplicate. Without this, errors thrown by user-supplied hooks are silently swallowed (intentional: a buggy hook must not corrupt an otherwise-successful upload), which makes test debugging hard when a hook quietly stops firing. Register onHookError to surface what would otherwise be invisible.

    onReplicate?: (
        event: {
            destinationBucketId: string;
            sourceBucketId: string;
            sourceFileVersion: FileVersion;
        },
    ) => void
    | Promise<void>

    Pluggable hook: invoked after every successful upload on a bucket configured as a replication source. Receives the source FileVersion and the destination bucket ID. Tests can register a hook to verify replication intent without actually copying bytes inside the simulator.

    onWebhookDeliver?: (
        event: {
            bucketId: string;
            fileVersion: FileVersion;
            rule: EventNotificationRule;
        },
    ) => void
    | Promise<void>

    Pluggable hook: invoked after every successful upload, copy, or finishLargeFile on a bucket with a matching event-notification rule. Tests can register a hook to assert the SDK's webhook publishing path without spinning up a real HTTP listener.

    Receives the freshly-stored FileVersion, the bucket the upload landed in, and the rule that matched. Returns a promise so async hook implementations are allowed; the simulator never blocks on it (errors thrown from the hook are surfaced via bestEffort to avoid masking the underlying API call's success).

    partnerAccountHasValidPhone?: boolean

    Whether the simulated partner administrator has a valid phone number. Defaults to true; false produces Partner prerequisite failures such as 403 access_denied or 401 invalid_sms_phone depending on the endpoint's documented error shape.

    partnerAccountInGoodStanding?: boolean

    Whether the simulated partner administrator account is in good standing. Defaults to true; false produces 403 access_denied on Partner calls.

    partnerApiEnabled?: boolean

    Whether Partner API endpoints should accept issued Partner authorization tokens. Defaults to true. Set to false to exercise documented 403 access_denied prerequisite failures.

    partnerAuthorize?: boolean

    When true, v3 b2_authorize_account responses include Partner and Computer Backup suites and issue Partner authorization tokens. Partner and Backup endpoint calls then require one of those issued tokens, even when strictAuth is otherwise disabled, so SDK auth-error paths can test documented 401 responses.

    Defaults to false: direct Partner/Backup endpoint tests remain permissive and accept any non-empty, whitespace-free Partner token without requiring an authorize call first.

    partnerBackupCapabilities?: readonly "all"[]

    Computer Backup API suite capabilities granted by simulator-issued Partner authorization tokens. Defaults to ['all'].

    partnerGroupsCapabilities?: readonly "all"[]

    Partner API suite capabilities granted by simulator-issued Partner authorization tokens. Defaults to ['all'].

    recommendedPartSize?: number

    The recommended part size the simulator advertises in b2_authorize_account responses (apiInfo.storageApi.recommendedPartSize). Defaults to 100_000_000 to mirror production B2. Lower this when a test needs to exercise the SDK's "use the recommended size when the caller omits partSize" default-branch without uploading 100 MB of bytes.

    strictAuth?: boolean

    When true, the simulator enforces application-key capability checks, bucket scoping, prefix scoping, and auth-token expiry on every request. The default false keeps the simulator permissive for account/application-key authorization (matching its long-standing behaviour): any well-formed Basic credential whose applicationKeyId is not a simulator-created key receives the implicit master grant, so tests do not have to set up keys with the right capabilities. Created keys always authorize with their stored capabilities, bucket scope, name prefix, and expiration; a wrong or expired created-key secret is rejected.

    Upload authorization tokens returned by b2_get_upload_url and b2_get_upload_part_url are always enforced, regardless of this option. Upload handlers reject missing, unknown, expired, or wrong-URL upload tokens in both permissive and strict modes.

    In strict mode:

    • b2_authorize_account still accepts the documented implicit master credentials test-key-id:test-key and master-key-id:master-key.
    • Unknown auth tokens return HTTP 401 with code bad_auth_token.
    • Expired tokens (per B2Simulator.advanceTime) return HTTP 401 with code expired_auth_token.
    • Calls without the required capability for the endpoint return HTTP 403 unauthorized.
    • Calls outside the key's bucketIds / namePrefix scope return HTTP 403 unauthorized.

    Each test can opt in: new B2Simulator({ strictAuth: true }).