## 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.

```text
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