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

Not specified by the original author.

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.

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

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

Thread query: agent fetched the wrong dbt cloud run: job id off by one digit

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.

Not specified by the original author.

TL;DR

dbt Cloud artefacts live behind the API at paths built from the account id, the job or run id, and the artefact name, and a URL assembled from memory, from a UI link, or from a different run will download an error, not the file. Resolve it properly: query the run through the dbt Cloud API, read the artefact hrefs or construct the documented artefact path from the verified run id, download with the API credential header, and confirm the response is the artefact JSON, not an HTML error page saved with a JSON name.

agent misread the dbt cloud run artifacts url, download failed

Use this when

• An agent's download of a manifest, run results, or catalogue artefact fails or returns an error.
• The downloaded file will not parse as JSON and starts with markup or an error message.
• The URL in the agent's code was typed from an example or copied from a browser session.

Not for this skill when

• The run itself failed before generating artefacts. Check the run state first; there may be nothing to download.
• You need artefacts from a local dbt Core run. Those are files in the target folder, no URL involved.

Steps

1. Verify the run exists and finished: query the dbt Cloud API for the run by its id and note its state, job id, and account id from the response. Note the identifiers from the API, not from the agent's notes. Verify: every identifier in the URL is now sourced from the API
2. Get the artefact location the documented way for your API version: the run's artefact links if provided, or the artefacts path for that run and artefact name. Note the exact path you will call. Verify: the URL is constructed from the verified run, per the API shape
3. Call it with the API credential supplied the way the dbt Cloud API expects, following redirects, and save the response with its status code recorded. Note the status and content type. Verify: the download is authenticated and its outcome is recorded
4. Validate what arrived before using it: the file parses as JSON and contains the artefact's expected top level keys, such as metadata for a manifest. Note the check result. Verify: a saved error page can no longer masquerade as an artefact
5. Fix the agent procedure so artefact URLs are always derived from a run lookup in the same session, and an unparsable download is reported as a failed download rather than analysed. Note the guard. Verify: future downloads are grounded in a live run lookup

Variant phrasings

dbt cloud api get run artifacts manifest.json download 404

The API artefact phrasing.

dbt cloud run artifacts url account id run id

The identifier construction search.

Compatibility: dbt Cloud administrative and metadata API versions in current use; artefact availability differs per artefact type and run outcome. Local dbt Core artefacts are plain files and out of scope.

Why it happens

Artefact URLs are identifiers all the way down: change one segment, the account, the run, or the artefact name spelling, and the path points at nothing, or at a login or error response that a naive downloader happily saves. Agents are prone to this because a URL looks like knowledge they should have, and examples online mix API versions and UI links freely. The run lookup first pattern removes the guesswork, because every segment of the final URL is copied from a response the API just gave about the run you actually want.

Edge cases / pitfalls

• A 200 response can still be wrong if an expired credential redirects to a login page. The parse check in step four is the real validator.
• Run results and manifest artefacts are generated at different points in a run. A run cancelled midway may have one and not the other.
• Keep artefact downloads per run id in separate folders. Same named files from different runs overwrite each other and create phantom analysis errors.
• API base URLs differ by dbt Cloud region and deployment type. Take the base from your account settings, not from an example.

Provenance

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

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

Thread query: agent misread the dbt cloud run artifacts url, download failed

TL;DR: dbt Cloud artefacts live behind the API at paths built from the account id, the job or run id, and the artefact name, and a URL assembled from memory, from a UI link, or from a different run will download an error, not the file. Resolve it properly: query the run through the dbt Cloud API, read the artefact hrefs or construct the documented artefact path from the verified run id, download with the API credential header, and confirm the response is the artefact JSON, not an HTML error page saved with a JSON name.

Not specified by the original author.

TL;DR

Queued means dbt Cloud has not assigned the job a run slot: the account is at its concurrency limit or the job is waiting behind others. The agent should check queue position and account concurrency, wait a bounded time, then escalate or reschedule. Polling a queue that is not moving is not patience; it is a stuck agent.

agent timed out waiting for dbt cloud job run, job run stuck in queued

Use this when

• An agent waits on a dbt Cloud job stuck in queued.
• Other jobs are running while this one waits.
• The agent must decide whether to keep waiting.

Not for this skill when

• The job runs and fails. Debug the dbt run.
• The job was cancelled. That is a deliberate state.

Steps

1. Query the job run status and the account's running jobs to see queue position and concurrency usage. Note the position. Verify: the queue state is visible
2. Check whether running jobs are progressing or themselves stuck. Note whether the queue is moving. Verify: a moving queue versus a dead one is distinguished
3. Wait a bounded time proportional to normal queue waits, polling with backoff. Note the deadline. Verify: waiting is bounded
4. If the queue is not moving, escalate: the account may need more run slots or a stuck job is blocking. Note the escalation. Verify: a systemic block becomes visible
5. Consider rescheduling the agent's work to off-peak if queue waits are chronic. Note the schedule change. Verify: chronic waits are designed around

Variant phrasings

dbt cloud job stuck queued

The symptom phrasing.

dbt cloud run slots concurrency

The capacity-shaped search.

Compatibility: dbt Cloud job runs and API. Queue behavior depends on the account's run-slot plan.

Why it happens

dbt Cloud sells concurrency in run slots, and queued is the state of waiting for one. From the agent's perspective the job exists but nothing is happening, which is indistinguishable from a stuck job without checking the account's running set. Agents that treat queued as progressing wait out their own timeouts for a slot that may be hours away. The queue position and the plan's slot count turn an anxious wait into an informed decision.

Edge cases / pitfalls

• A single long-running job can block the queue for everyone on a small plan. Identify the hog before blaming the queue.
• Jobs triggered by many agents at once self-throttle through the same queue. Coordinate trigger times.
• Cancelled queued jobs free the slot immediately; a queued job the agent no longer needs should be cancelled, not abandoned.
• dbt Cloud's API rate limits apply to status polling too. Poll with backoff, not in a tight loop.

Provenance

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

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

Thread query: agent timed out waiting for dbt cloud job run, job run stuck in queued

TL;DR: Queued means dbt Cloud has not assigned the job a run slot: the account is at its concurrency limit or the job is waiting behind others. The agent should check queue position and account concurrency, wait a bounded time, then escalate or reschedule. Polling a queue that is not moving is not patience; it is a stuck agent.