## TL;DR

Run and job ids are long numbers with no check digits, so a single digit error silently points at a real but wrong run. Anchor the agent to ids taken from the failing run URL or API response (never retyped), cross-check job name, environment, and start time on the fetched run, and only then read its artifacts. A mismatch on any cross-check means stop and refetch.

```text
agent fetched the wrong dbt cloud run: job id off by one digit
```

## Use this when

- an agent diagnosis cites step logs or artifacts that do not match the failure you saw
- the fetched run shows a different job name, time, or git commit than the failing run
- ids were copied by hand or generated by the agent rather than taken from a URL or API listing

## Not for this skill when

- the run really is the failing one and its logs are confusing, debug the run content instead
- artifacts are missing for the correct run (job without artifact steps), change the job config
- you are on self-hosted dbt, correlate by your orchestrator run ids with the same cross-check discipline

## Steps

1. Get the authoritative id: open the failing run in dbt Cloud and copy the run id from the URL, or list recent runs via the API filtered by job and pick the one with the failing timestamp.
   Verify: the run id comes from the Cloud UI or API listing, not from memory or retyping.

2. Fetch that run details and verify three fields before reading logs: job name, environment name, and started time (plus git sha if available). Compare each against the failing job record.
   Verify: all cross-check fields match the intended run.

3. Only then download artifacts (run_results.json, manifest.json) for that run id and base the diagnosis on them, citing the run id and job name in the report.
   Verify: the diagnosis references artifacts from the verified run.

4. Fix the agent procedure: pass run ids through tool outputs programmatically, add the three-field verification as a mandatory step, and fail loudly on mismatch.
   Verify: the agent verifies identity before analysis on the next incident.

## Variant phrasings

### off by one in job id, not run id
Fetching the right run of the wrong job is the same failure. Cross-check job name catches it.

### two runs started in the same minute
Retries and manual retriggers create near-identical runs. Use the run id, not the timestamp alone, and check the trigger type field.

Compatibility: dbt Cloud jobs, runs, and artifacts via UI and API (accounts, jobs, runs endpoints). Ids are numeric and must be handled as exact strings or integers from API output.

## Why it happens

Nothing about a mistyped id looks wrong: neighbouring ids usually belong to real runs of real jobs, often the same job a day apart, so every artifact the agent reads is internally consistent and confidently wrong. Only cross-checking independent fields (name, environment, time, commit) against the incident record exposes the substitution.

## Edge cases / pitfalls

- Agent reports should always carry the run id and job name together so a human can spot a mismatch at a glance.
- Do not let agents increment or guess ids to find the latest run; list runs through the API with filters.
- Artifact downloads cached by run id in agent memory can go stale across incidents; key caches by verified id plus timestamp.

## Provenance

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