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

    Interface B2SimulatorOptions

    Options for constructing a B2Simulator.

    interface B2SimulatorOptions {
        authTokenTtlMs?: number;
        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>;
        recommendedPartSize?: number;
        strictAuth?: boolean;
    }
    Index

    Properties

    authTokenTtlMs? minimumPartSize? onHookError? onReplicate? onWebhookDeliver? recommendedPartSize? strictAuth?

    Properties

    authTokenTtlMs?: number

    How long auth tokens issued via b2_authorize_account are valid for, in milliseconds. Defaults to 24 hours (real B2). Tests that want to exercise the 401/reauth retry path can lower this so a single call to B2Simulator.advanceTime expires the token.

    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).

    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 (matching its long-standing behaviour) so the existing test suite doesn't have to set up keys with the right capabilities.

    In strict mode:

    • 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 bucketId / namePrefix scope return HTTP 403 unauthorized.

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

    Settings

    Member Visibility

    On This Page

    Properties