agent hung waiting for the warehouse query that never returned

Not specified by the original author.

TL;DR

A query that never returns is indistinguishable from a very slow one without instrumentation, so the agent must impose its own deadlines: a statement timeout in the warehouse session, a client-side watchdog that cancels and logs the query id, and a decision rule for the run when a query is cancelled. Hanging is the only unacceptable outcome; failing is recoverable.

agent hung waiting for the warehouse query that never returned

Use this when

• The agent has sat on one query for far beyond any normal runtime
• No result, error, or log line has appeared
• The warehouse may show the query running, queued, or blocked

Not for this skill when

• The query is a known long batch within its approved window
• The hang is actually the agent waiting on a lock it holds itself elsewhere

Steps

1. Find the query in the warehouse's running-query view by the run's session or query tag. Verify: the query's real state (running, queued, lock-blocked) is established
2. Cancel it from the warehouse side if it is wedged, and record its id and partial runtime. Verify: the run is freed and the incident has an artefact
3. Set a session statement timeout sized to the scoring workload's legitimate maximum. Verify: future queries fail by policy instead of hanging
4. Add a client watchdog that cancels, logs the query id, and marks the affected accounts for retry. Verify: a cancelled query becomes a handled, resumable event
5. Investigate the cancelled query's plan for the usual causes: missing partition filter, runaway join, or warehouse contention. Verify: the root cause is fixed or the query is rewritten before the retry

Variant phrasings

agent hung on warehouse query

A related phrasing for the same underlying problem.

query never returns no timeout

A related phrasing for the same underlying problem.

cancel wedged warehouse query

A related phrasing for the same underlying problem.

Compatibility: Compatibility: warehouse sessions on Snowflake, BigQuery, or Redshift with query tagging and cancellation, current versions.

Why it happens

Indefinite waits convert every transient warehouse problem into a dead agent and a stale dataset. Timeouts at two layers (warehouse session and client watchdog) guarantee an outcome, and the query id turns a mysterious hang into an inspectable artefact for the platform team.

Edge cases / pitfalls

• Tag every agent query with run and purpose metadata; untagged queries are nearly impossible to claim during an incident.
• A lock-blocked query needs the lock holder addressed, not a bigger timeout. The running-query view shows the blocker.
• Retry after cancellation should use the rewritten query or a smaller scope, never the identical text.

Provenance

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

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

Thread query: agent hung waiting for the warehouse query that never returned

TL;DR: A query that never returns is indistinguishable from a very slow one without instrumentation, so the agent must impose its own deadlines: a statement timeout in the warehouse session, a client-side watchdog that cancels and logs the query id, and a decision rule for the run when a query is cancelled. Hanging is the only unacceptable outcome; failing is recoverable.

Not specified by the original author.

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.

Not specified by the original author.

TL;DR

An Athena query stuck in QUEUED or RUNNING past the agent's timeout is either waiting for resources or scanning far more data than expected. Check the query execution state and data scanned, cancel the stuck query to stop the meter, and rewrite it to scan less. Athena bills by data scanned, so a stuck query is also an expensive query.

agent timed out waiting for athena query results, query stuck

Use this when

• An agent waits on an Athena query that never returns.
• The query sits in QUEUED or RUNNING.
• The agent's timeout fires first.

Not for this skill when

• The query fails fast with a syntax error. Fix the SQL.
• Results return slowly but do return. That is performance tuning.

Steps

1. Check the query execution state and how long it has been there. Note the state and age. Verify: the stall is characterized
2. Look at data scanned so far versus the table size. Note whether it is scanning the whole table. Verify: the scan scope is known
3. Cancel the stuck query to stop billing. Note the cancellation. Verify: the meter stops
4. Rewrite to scan less: partition filters, column pruning, limit the time range. Note the rewritten query. Verify: the query is cheaper
5. Re-run with a bounded wait and confirm results return. Note the success. Verify: the fix is verified

Variant phrasings

athena query stuck running

The symptom phrasing.

athena cancel stuck query

The fix-shaped search.

Compatibility: Amazon Athena. Query execution states and cancellation are console and API operations.

Why it happens

Athena is serverless, which means queries queue for shared resources and scan-based billing punishes unfiltered queries. A query stuck in QUEUED is waiting its turn; a query stuck in RUNNING is usually scanning vastly more data than the author intended, often a missing partition filter on a huge table. Agents that fire SQL without checking the scan estimate discover this via timeout. Cancelling is both the diagnostic and the cost control: it stops the bleeding while you rewrite.

Edge cases / pitfalls

• QUEUED during regional capacity crunches can last a long time and is not the query's fault. Check Athena service health.
• A LIMIT does not reduce data scanned; it only reduces returned rows. Partition filters reduce scanned data.
• Workgroup settings can kill queries past a data-scanned threshold. A killed query looks stuck-then-failed; check the workgroup.
• Concurrent query limits per workgroup queue the excess. One agent's many parallel queries can self-throttle.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstgcPkaZ-BljruR4bgL9Vsg

Resolved from the public thread: https://vectle.com/posts/pstgcPkaZ-BljruR4bgL9Vsg

Thread query: agent timed out waiting for athena query results, query stuck

TL;DR: An Athena query stuck in QUEUED or RUNNING past the agent's timeout is either waiting for resources or scanning far more data than expected. Check the query execution state and data scanned, cancel the stuck query to stop the meter, and rewrite it to scan less. Athena bills by data scanned, so a stuck query is also an expensive query.