Did That Snowflake Task Actually Fail?

An affected task scheduled before the restarts and not run afterwards may fail once more despite a successful query. Graph history remains incomplete, without a restoration estimate.

Snowflake advises checking query history before retrying, and rerunning if the query failed. For an operator, the consequential question is what a replay would actually repeat.

Find the statement behind the task

The QUERY_HISTORY view provides statement identifiers, execution status, user, warehouse, query tag and start/end times. Account Usage can lag by 45 minutes. The documented record is therefore useful evidence, but an immediate absence should not be turned into a finding that nothing ran.

The COMPLETE_TASK_GRAPHS function exposes the root query’s start time for correlation with query history. Its ordinary results cover the past hour and have a row limit, so even outside an incident, an absent graph is not conclusive evidence of non-execution.

In this incident, Snowsight may omit pre-incident and later runs. Completed-graph results may miss recent runs; current-graph results may retain stale rows. Account Usage graph history retains pre-incident runs but may omit later ones.

Follow a settlement batch to its recipient

Consider a hypothetical hourly settlement process. A root task writes one approved batch to a staging table, a child creates a partner file, and the partner’s receipt is stored separately. The intended unit of work is the settlement batch, not an arbitrary collection of green task labels.

Suppose the operator sees a failed root task, then finds the expected staging entry and a successful statement result. Replaying the complete graph could create another batch. Instead, the operator follows that batch’s identifier through the file-generation record and the partner’s receipt. A match across those records would justify a different decision from an unexplained staging entry with no known delivery.

In the first case, the file owner can record that the expected delivery already happened and why a replay was declined. In the second, the incident owner keeps the delivery question open. They should agree whether a narrowly bounded recovery is possible rather than allowing a scheduler label to decide which business actions may be repeated.

This is an illustrative workflow, not a reported Snowflake customer incident or a claim that the provider caused duplicate settlements. It separates the evidence that the database can supply from the evidence that the business process must supply.

A successful query is not a delivery receipt

Snowflake’s query-history documentation makes that distinction concrete for PUT and GET: a success status means authorisation to proceed with a transfer, not confirmation that the files were uploaded or downloaded. That is a reason to ask for the actual transfer outcome, not to assume every successful query has the same meaning.

For the hypothetical settlement, the handover note should identify the batch, the statement reviewed, the expected partner output and the person who accepted the replay decision. If evidence is unavailable, name the missing record and who will obtain it. A colleague taking the next shift should be able to understand why the first operator acted or waited without repeating the entire investigation.

Snowflake provisionally attributes inconsistent task metadata to regional infrastructure. The incident remains open, without a final cause or published affected-customer count.

Those limits matter even after one batch is reconciled. The organisation can finish its own delivery decision while keeping the unresolved provider questions visible. Neither a successful statement nor an unexplained failure should approve more work than its evidence supports.

Sources: Snowflake INC20000277; QUERY_HISTORY; COMPLETE_TASK_GRAPHS.