Snowpipe Streaming Node.js SDK v1.8.0
    Preparing search index...

    Class ErrorDetail

    The payload handed to an elastic-channel error handler (registered via StreamingIngestElasticChannel.setErrorHandler) when appends fail asynchronously.

    Delivered once per failure event, carrying the caller-supplied append tokens of every append that failed together under a common error — a whole server-ack error batch, or every tracked in-flight append on channel invalidation.

    Instances are created by the SDK and frozen; handlers only read this type, so new fields can be added over time without breaking them.

    Index

    Properties

    appendTokens: readonly unknown[]

    The opaque, caller-supplied append tokens of the appends that failed with error. Never empty; a token reused across appends appears once per failed append (not deduplicated). Frozen at construction — the array itself cannot be modified, though the tokens inside it are the caller's own objects.

    The error that rejected the failing appends.

    requestId: string

    The Snowflake request id of the server response that failed these appends, for support escalation. Null when the failure did not come from a server response — channel invalidation, or a protocol inconsistency the SDK detected on its own.

    retryCount: number

    How many retries the failing request had already made: 0 when the first attempt failed, N when the SDK retried N times before giving up.

    Use this to decide whether these rows may be duplicated in the table. A retry re-sends the same rowset, and the SDK retries whenever it cannot tell that the previous attempt failed — a timeout or a 5xx may mean the rows were never processed, or that they were processed and only the response was lost. 0 means the SDK sent this rowset once and introduced no duplicate; > 0 means it sent it more than once and an earlier attempt may already have been applied, so the rows may appear more than once. Reconcile or de-duplicate downstream if you need exactly-once.

    The signal is conservative: it counts every re-send, including an authentication refresh, which is rejected before the rows are processed and so cannot have duplicated anything. > 0 means "a duplicate is possible", not "a duplicate happened". 0 means the SDK introduced no duplicate of its own, not that the rows are absent from the table.

    Whenever requestId is null, neither field tells you whether the rows arrived. A null id means the SDK failed this append itself rather than relaying a server response — channel or client invalidation, a close or drop, or an internal fault — and all of those fail every append still in flight, locally and immediately. That includes appends whose request had already gone to Snowflake and may still be applied after this handler runs. The accompanying retryCount of 0 says only that the SDK sent the rowset once; it is not a statement that Snowflake rejected it. Reconcile against the table if you need to know whether those rows landed.

    Read it only when requestId is non-null: a failure with no originating request reports 0 too. With the request id this names the exact attempt server-side — the SDK sends both as query params on every request.