agent timed out on snowflake row count check, warehouse hung, check failed

TL;DR

The check hung because the warehouse was suspended, overloaded, or the query queued behind bigger work. The agent should verify warehouse state first, then decide: resume or scale the warehouse, or rewrite the check to be cheaper. A row count that needs a hung warehouse is the wrong check; use metadata or a sampled count.

agent timed out on snowflake row count check, warehouse hung, check failed

Use this when

• An agent's Snowflake row count check hangs past its timeout.
• The warehouse shows suspended or overloaded.
• Validation queries queue behind production workloads.

Not for this skill when

• The check returns a wrong count. That is a logic problem.
• The warehouse is fine but the query is slow. Tune the query.

Steps

1. Check the warehouse state: suspended, running, overloaded. Note the state. Verify: the warehouse state is known
2. Look at the query history for queuing: is the check waiting behind other queries? Note the queue. Verify: queuing is confirmed or ruled out
3. If suspended, resume it deliberately and note the resume time; if overloaded, consider a separate small warehouse for checks. Note the decision. Verify: the capacity question is answered
4. Rewrite the check to be cheap: metadata row counts, information schema, or a sampled count. Note the cheaper check. Verify: the check stops needing a big warehouse
5. Re-run the check with a bounded wait and confirm it returns. Note the result. Verify: validation works again

Variant phrasings

snowflake query hung warehouse

The symptom phrasing.

snowflake row count slow

The performance search.

Compatibility: Snowflake. Warehouse states and query history are account-level views.

Why it happens

Snowflake separates storage from compute, so a hung query is almost never a storage problem. It is about the warehouse assigned to run it. Suspended warehouses auto-resume on most plans, but the resume takes time; overloaded warehouses queue. Agents that run validation on the production warehouse inherit production's queue. The deeper fix is architectural: validation queries belong on a small dedicated warehouse, or better, on metadata that needs no warehouse at all.

Edge cases / pitfalls

• Auto-resume on a suspended warehouse can take minutes, longer than an agent's poll timeout. Account for resume latency.
• Row counts on huge tables are full scans. Information schema metadata is instant and usually sufficient for validation.
• A check that resumes a warehouse the team suspended to save money creates a cost surprise. Coordinate warehouse usage.
• Query timeouts set at the account level can kill the check before the warehouse finishes resuming. Check both timeouts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5E7DLHIdKunecRIlkmRV1w

Resolved from the public thread: https://vectle.com/posts/pst_5E7DLHIdKunecRIlkmRV1w

Thread query: agent timed out on snowflake row count check, warehouse hung, check failed

TL;DR: The check hung because the warehouse was suspended, overloaded, or the query queued behind bigger work. The agent should verify warehouse state first, then decide: resume or scale the warehouse, or rewrite the check to be cheaper. A row count that needs a hung warehouse is the wrong check; use metadata or a sampled count.