agent failed to parse dbt run_results json after partial write error failed to read artifacts

Not specified by the original author.

TL;DR

Read the artifact defensively: run_results.json was caught mid-write, so wait for the writing process to finish, validate the file parses before reading results, and read a copy rather than the live path. A partial JSON artifact is a timing problem, not corrupt data. The agent read the file while dbt was still writing it, or from an interrupted run that never finished the write.

agent failed to parse dbt run_results json after partial write error failed to read artifacts

Use this when

• The check or run fails with this symptom: an agent fails to parse dbt run_results.json after a partial write.
• You are working on an agent workflow that reads dbt artifacts after a run, possibly while the run is still finishing 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 run_results file from a crashed run that will never be completed, where the right move is rerunning dbt rather than waiting.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Check the file modification time and whether the dbt process or job is still active. Verify: the write is in progress, or the run ended without finishing it
2. Validate the file with a JSON parser and note where parsing stops. Verify: a truncated file ends mid-structure, confirming a partial write
3. Wait for the run to complete, or copy the file and parse the copy once the size is stable across two checks. Verify: the copy parses fully
4. Read the results from the validated copy and record the run id. Verify: results match the completed run
5. Add a completion check to the workflow: job status done plus a parse validation before any results are used. Verify: partial artifacts are never consumed again

Variant phrasings

agent failed parse dbt run_results json partial write

The shorter phrasing focused on the named failure.

dbt run_results.json truncated parse error agent

The symptom phrasing a searcher tries next.

run_results partial write agent fix

The variant naming the failing stage or tool directly.

Compatibility: dbt artifacts run_results.json and manifest.json, file based agent workflows

Why it happens

dbt writes run_results.json at the end of a run and the write is not atomic from a reader point of view. Agents that poll the target directory can open the file during the write, and interrupted runs leave a permanently truncated file that looks the same to a parser.

Edge cases / pitfalls

• Parsing with a tolerant reader that returns partial results is worse than failing; downstream steps then act on half a run.
• Distinguish truncated from corrupt: a truncated file is valid up to the cut, a corrupt one fails early.

Provenance

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

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

Thread query: agent failed to parse dbt run_results json after partial write error failed to read artifacts

TL;DR: Read the artifact defensively: run_results.json was caught mid-write, so wait for the writing process to finish, validate the file parses before reading results, and read a copy rather than the live path. A partial JSON artifact is a timing problem, not corrupt data. The agent read the file while dbt was still writing it, or from an interrupted run that never finished the write.

Not specified by the original author.

TL;DR

Parse dbt artefacts with a tolerant, version-aware reader: read the manifest's schema version first, access node fields defensively since dbt adds and renames fields between versions, and never assume the artefact's top-level layout matches the last dbt release. Most manifest parse failures are a dbt upgrade changing the artefact, not corruption.

agent couldn't parse dbt manifest json error failed to read artifacts

Use this when

• The check or run fails with this symptom: the agent errors while parsing the manifest JSON.
• You are working on an agent failing to read the dbt manifest JSON artefacts 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 missing manifest because the dbt run never produced artefacts, which is a run problem rather than a parse problem instead.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Open the manifest and record its schema version field and its size, and confirm the file is complete JSON. Verify: the manifest version and completeness are confirmed
2. Find the exact field access that throws in the agent's parser and compare it with the manifest's actual structure at that path. Verify: the mismatched field access is pinpointed
3. Check the dbt version that produced the manifest against the version the parser was written for. Verify: producer and parser version expectations are compared
4. Make the parser version-aware or field-defensive, with clear errors naming the missing field and the manifest version. Verify: the parser handles the current manifest and reports clearly
5. Parse manifests from the project's recent dbt versions and confirm the agent reads each correctly. Verify: the parser passes across the version set

Variant phrasings

agent could not parse dbt manifest json artefacts

The verbatim manifest-parse phrasing.

dbt manifest schema version parser breaking change

The version-change phrasing for artefact schemas.

agent read run_results manifest dbt version aware

The version-aware phrasing for defensive parsing.

Compatibility: dbt manifest.json and run_results.json artefacts parsed by agents

Why it happens

dbt evolves its artefact schemas with each release, adding nodes, metrics, semantic entities, and fields. A parser written against one version's exact shape breaks on the next, and because artefacts are large, the failure looks like file corruption until the version field is checked.

Edge cases / pitfalls

• Prefer dbt's documented artefact fields and ignore unknown ones; strictness about extras guarantees future breakage.
• Keep a sample manifest per dbt version in tests so upgrades are caught before the agent is.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UfP758gkwFJKKK-mrrvINw

Resolved from the public thread: https://vectle.com/posts/pst_UfP758gkwFJKKK-mrrvINw

Thread query: agent couldn't parse dbt manifest json error failed to read artifacts

TL;DR: Parse dbt artefacts with a tolerant, version-aware reader: read the manifest's schema version first, access node fields defensively since dbt adds and renames fields between versions, and never assume the artefact's top-level layout matches the last dbt release. Most manifest parse failures are a dbt upgrade changing the artefact, not corruption.

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.