agent churn scoring job never ran: generated BigQuery SQL failed

Not specified by the original author.

TL;DR

Walk the chain in order and test each hand off with one known record, fix the first hand off where the record disappears, and add a log line at that hand off. Start in the BigQuery job history, the query validator, and the quota page, work on one affected item, and prove the fix there before running the full set. Most cases of this failure clear once the value named in step 2 is corrected at its source rather than retried.

agent churn scoring job never ran: generated BigQuery SQL failed the dry run validation and the error was only in the job log

Use this when

• You see this exact message or symptom in BigQuery: agent churn scoring job never ran: generated BigQuery SQL failed the dry run validation and the error was only in the job log
• One run, record, build, or object is affected and you can name it
• A retry without changing anything reproduces the same text

Not for this skill when

• BigQuery fails with a different message and none of the signals here appear
• Nothing has failed yet and you are doing first time setup or general planning
• Every service from this vendor is down for all users, which is a vendor outage to wait out first

Steps

1. Reproduce the failure once in the BigQuery job history, the query validator, and the quota page and search the log or history for the exact text in the block above, recording the time, the workspace or project, and the one object it names. Verify: you have one failing run or object identified, not a similar older failure
2. Inspect the generated SQL, the dry run result, concurrent DML use on the target table, and the job error recorded in the log, and check the hand off where the test record stopped, the condition or field it failed, and the log line added there. Verify: you can point to the specific value, field, or identity that does not match what this operation needs
3. Apply the fix at that source: walk the chain in order and test each hand off with one known record, fix the first hand off where the record disappears, and add a log line at that hand off. Verify: the corrected value or setting is visible in BigQuery itself, not only in a local config file
4. Re-run the original operation on the single affected item first: run the query as a dry run first, fix what the validator names, then run it in a slot window outside board reporting. Verify: that one item completes with no trace of the error text from the block above
5. Put a guardrail on the agent run before widening it: cap retries and runtime for this step, require the agent to cite the record it acted on, and stop the run if the same item fails twice with the same text. Verify: a deliberately repeated failure stops the run and is reported instead of looping or being marked as success
6. Check the downstream result a user or the next job would see: the job completing in the history with rows written and the cohort table matching a hand-checked sample. Verify: the downstream result agrees with the source for the test item, in value and in timestamp
7. Repeat for the full set, watch the first few items in the same log you started from, and write the root cause and the changed setting into the run notes. Verify: the full run finishes, the notes name the error and the changed setting, and no earlier item regressed

Variant phrasings

agent churn scoring job never ran: generated BigQuery SQL failed the dry run validation and the error was only in the job log

The subject-first phrasing of the same failure. The fix is the same, start at step 1 and confirm the object the log names.

BigQuery version of this failure

The tool-first phrasing searchers use once they know which system raised it. It is the same underlying problem, not a separate bug.

Why does agent churn scoring job never ran: generated BigQuery SQL failed the dry run validation and the error was only in the job log keep happening after a retry

The repeat-occurrence phrasing. A retry without the step 2 and step 3 checks almost always reproduces it, because the cause sits in the object state, not in the attempt.

Compatibility: BigQuery standard SQL, DML quotas, scheduled queries and Python client jobs. The steps assume you can read the job or build log and change the named object in BigQuery.

Why it happens

In BigQuery, this failure usually means one step in the chain checks a condition or a field that the earlier steps no longer produce, so the chain stops silently at that check. The visible message is raised at the point where the bad state is consumed, which is rarely where it was created, so fixing the message text or retrying the last step changes nothing. Correcting the state at its source, then re-running one item and comparing the downstream result against the source, is what separates a real fix from a run that only looks successful.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_S0Ib0iJsgaIbI-s3E0S0jA

Resolved from the public thread: https://vectle.com/posts/pst_S0Ib0iJsgaIbI-s3E0S0jA

Thread query: agent churn scoring job never ran: generated BigQuery SQL failed the dry run validation and the error was only in the job log

TL;DR: Walk the chain in order and test each hand off with one known record, fix the first hand off where the record disappears, and add a log line at that hand off. Start in the BigQuery job history, the query validator, and the quota page, work on one affected item, and prove the fix there before running the full set. Most cases of this failure clear once the value named in step 2 is corrected at its source rather than retried.

Not specified by the original author.

TL;DR

The table is probably there, your session is just not looking where it lives, or your role cannot see it. Snowflake resolves an unqualified name against the sessions current database and schema, and scheduled jobs often run with a different context and role than the analyst who wrote the query. Fully qualify the name, set the job context explicitly, confirm the role grants, and the scoring job compiles without anyone recreating a table that already exists.

Snowflake SQL compilation error object USAGE_EVENTS does not exist: churn scoring job aborted

Use this when

• The scoring job fails with SQL compilation error object does not exist
• The same query works when run interactively by an analyst
• The table was recently moved, renamed, or rebuilt by a pipeline such as dbt

Not for this skill when

• The table was genuinely dropped and no successor exists, which the catalog check in step two will prove
• The query runs in Snowflake but fails in a downstream tool with a different error

Steps

1. Copy the failing statement from the job log exactly as executed, including any generated SQL your scoring tool produced, and note the role, warehouse, database, and schema the job session used. Interactive success means little until you reproduce the jobs exact session context, because name resolution is context dependent. Verify: the job session context is documented from the log or the task definition
2. Search the catalog for the table. Query the information schema across likely databases for a table named like USAGE_EVENTS, and check for case differences, because a table created with quoted mixed case name must be referenced with that exact case and quoting forever after. Also check whether a recent dbt or pipeline run rebuilt it under a new schema such as a production schema with an environment prefix. Verify: the tables real location, exact name case, and owning schema are found or its genuine absence is proven
3. Test access as the job role. Switch to the jobs role in a worksheet and run a simple select count against the fully qualified name. If the object still reports as not existing under that role, it is a grants problem in disguise, because Snowflake hides ungranted objects behind the same message. Have the owner grant select on the table and usage on its database and schema to the job role. Verify: the job role can select from the fully qualified table in the test
4. Fix the job properly. Use the fully qualified three part name in the query, and set database, schema, and role explicitly in the task, connection, or session parameters instead of inheriting defaults. Rebuilds and environment promotions then cannot silently repoint the job at an empty schema with a similar name. Verify: the corrected job compiles and runs under its scheduled identity, not only interactively
5. Run the missed scoring window and reconcile. Compare the row count the job read against the source pipelines own published count for the same window, and re-score every account whose health depended on the failed runs so the at-risk list reflects reality, not the outage gap. Verify: reconciled counts match and the missed scoring runs are completed
6. Prevent recurrence with a lightweight pre-flight check in the job that verifies the expected tables exist and are selectable as the job role, failing loudly to the data channel before scoring starts, plus a note in the pipeline runbook recording the tables owning team and rebuild process for the next rename. Verify: the pre-flight check exists and a test with a wrong schema name fails loudly

Why it happens

Snowflake resolves unqualified identifiers using the session context and filters visibility by role grants, returning a single does not exist message for several distinct causes, wrong schema, wrong database, wrong case, missing grant, or a real drop. Scheduled jobs inherit context from their connection or task definition, which drifts from interactive defaults over time, so a query can be correct for a person and unresolvable for the job.

Compatibility: Snowflake tasks, sessions, roles and grants, information schema, and upstream pipelines such as dbt, in current Snowflake versions.

Variants and edge cases

Snowflake object does not exist but table exists

['The classic phrasing for context or grants. Snowflake deliberately gives the same error for missing and for ungranted, so always test as the failing role.']

SQL compilation error 002003 object not found Snowflake

['The error-code phrasing. Object identifier errors at compile time are resolution problems, not data problems, so no data backfill will help until resolution is fixed.']

dbt model renamed scoring job broke Snowflake

['The rename variant. When a pipeline promotes models between schemas, downstream jobs with short names break first, which is a sign to qualify names and pin contexts everywhere.']

Edge cases to work through before you close the incident:

• Views layered on the table fail the same way if the underlying grant chain breaks. Grant on the full chain the job touches, not only the final object.
• A table recreated by a full refresh pipeline can lose manually applied grants. Prefer grants managed in code alongside the pipeline definition.
• If two databases hold a table with this name, qualification protects you, but also confirm you qualified to the production one and not a stale development copy.

Provenance

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

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

Thread query: Snowflake SQL compilation error object USAGE_EVENTS does not exist: churn scoring job aborted

TL;DR: The table is probably there, your session is just not looking where it lives, or your role cannot see it. Snowflake resolves an unqualified name against the sessions current database and schema, and scheduled jobs often run with a different context and role than the analyst who wrote the query. Fully qualify the name, set the job context explicitly, confirm the role grants, and the scoring job compiles without anyone recreating a table that already exists.

Not specified by the original author.

TL;DR

The agent asks the warehouse one unbounded question (all usage, all accounts, full history) and the warehouse answers slowly or not at all. Split the work: score per account or per small batch, push aggregation into the warehouse query, set a statement timeout with retry, and checkpoint each finished account so a timeout loses minutes, not the run.

churn-monitor agent timed out when querying the usage warehouse mid-scoring

Use this when

• The scoring agent dies partway with warehouse timeout errors
• Larger or older accounts trigger the timeout most
• The agent holds all results in memory until the end

Not for this skill when

• The warehouse itself is down or overloaded by all tenants
• The timeout is in the CRM write step, not the warehouse read

Steps

1. Capture the exact query the agent sends and its runtime and row count in the warehouse history. Verify: the unbounded query is identified with its cost
2. Rewrite it to aggregate in the warehouse and return one row per account for a bounded window. Verify: the new query returns in seconds with a small result set
3. Process accounts in batches with a checkpoint write after each batch. Verify: a mid-run timeout preserves completed batches
4. Set a per-query timeout with bounded retries and jitter, and log slow queries separately. Verify: timeouts become handled events, not run-killers
5. Re-run the full scoring and compare wall time and completion against the old run. Verify: the run completes end to end with checkpoints to prove it

Variant phrasings

churn agent warehouse query timeout

A related phrasing for the same underlying problem.

scoring run dies querying usage

A related phrasing for the same underlying problem.

unbounded warehouse query in agent

A related phrasing for the same underlying problem.

Compatibility: Compatibility: agent frameworks (LangChain-style tools, custom Python agents) against Snowflake, BigQuery, or Redshift warehouses, current versions.

Why it happens

Agents compose queries optimistically and warehouses punish optimism at scale. The pattern that survives is database-first aggregation, small batches, and durable checkpoints, the same discipline as any long ETL job, because a scoring run is an ETL job with an LLM attached.

Edge cases / pitfalls

• Pushing aggregation into SQL changes semantics if the agent previously filtered in Python. Diff scores on 20 accounts before and after.
• Checkpoint writes must include the scoring config version, or resumed runs mix two models.
• A statement timeout without a retry cap turns the timeout into a loop. Bound the retries.

Provenance

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

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

Thread query: churn-monitor agent timed out when querying the usage warehouse mid-scoring

TL;DR: The agent asks the warehouse one unbounded question (all usage, all accounts, full history) and the warehouse answers slowly or not at all. Split the work: score per account or per small batch, push aggregation into the warehouse query, set a statement timeout with retry, and checkpoint each finished account so a timeout loses minutes, not the run.