auth token expired mid-dbt cloud job run failure agent stopped

TL;DR

Mid-job credential expiry in dbt Cloud breaks the agent, not the job: the dbt Cloud run usually continues server-side, so the agent should re-authenticate, reattach to the run by its identifier, and poll its status to completion. Designing the agent to treat its own session loss as job failure produces duplicate runs when it blindly retries.

auth token expired mid-dbt cloud job run failure agent stopped

Use this when

• The check or run fails with this symptom: the agent stops mid-job after its dbt Cloud authentication expires.
• You are working on an agent driving a dbt Cloud job that loses authentication mid-run and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A dbt Cloud job that itself failed on a model error, where reattaching only reports the real failure instead.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Check the dbt Cloud run's state through a fresh session to see whether the job continued after the agent dropped. Verify: the job's true state is established independently
2. Record run identifiers at job start in the agent's persistent state so any session can reattach. Verify: run identifiers are stored at start
3. Implement re-authentication and reattach: on an authentication error, refresh the session and resume polling the stored run. Verify: reattach logic is implemented and tested
4. Prevent duplicate submission: before starting a job, check for an existing active run from the stored identifier. Verify: duplicate submission is guarded
5. Simulate a session expiry during a run and confirm the agent recovers and reports the job's real outcome. Verify: the simulation ends with the correct outcome reported

Variant phrasings

auth expired mid dbt cloud job run agent stopped

The verbatim dbt Cloud expiry phrasing.

dbt cloud agent reattach run after session expiry

The reattach phrasing for stored run identifiers.

agent duplicate dbt cloud run retry session loss

The duplicate-run phrasing for blind retries.

Compatibility: dbt Cloud jobs driven by an agent through the dbt Cloud API

Why it happens

The agent and the job have separate lifetimes: dbt Cloud executes runs server-side regardless of whether the submitting session survives. Agents that conflate their session state with job state both lose results and, on retry, stack duplicate runs on the same models.

Edge cases / pitfalls

• Poll with the run's own status endpoint rather than resubmitting status queries as new jobs.
• Store the run identifier outside the agent's memory so a full agent restart can still reattach.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Gc8GJuFSw-7ZsOEesmJ82g