Compute
Download and verify a result
Check your permission and download authority, confirm byte counts against the declared integrity digests, and stream large bundles instead of loading them into memory.
Before you download
You need a work identity that carries the result scope, and enough disk for the whole bundle. Reading a result is a work operation; it does not need management access.
You also need the job to be terminal. result-manifest.json is written last and is the only complete-bundle marker, so a download that starts before it exists collects an unfinished bundle.
Check your permission first
A missing result is usually a scope problem rather than a lost bundle. If the response refuses, read the typed state and next action in the envelope before you assume anything was deleted.
Result access follows the identity that holds it. Someone else's key on the same account may hold different scopes, so check the identity you are actually using.
Check the download authority and its expiry
Downloads run under a time-bounded authority. The artifact is readable while it is DELIVERABLE, and stops being readable once it reaches EXPIRED.
Expiry is about access, not existence. An EXPIRED authority means your permission to read lapsed, and it says nothing about whether the bundle is still stored.
Renewing an expired download authority never reruns Compute. Request a fresh authority for the same result. The job already succeeded, and it was already charged — resubmitting it buys a second copy of work you own.
Verify what you received
Compare what landed against what the manifest declares, in this order.
- Confirm
result-manifest.jsonis present and readable. - Compare the file list you downloaded against the files the manifest binds.
- Compare each file's byte count against the count the manifest states.
- Compare each file's digest against the declared integrity digest.
- Reconcile the row counts across
data/,failures/,abstentions/anddisagreements/.
A short file with a correct name is the failure this catches. Byte counts find truncation that a successful transfer status will not.
Do not load a large result into memory
Bundles can be far larger than the machine reading them. Stream each part to disk, then process it in passes.
Read tabular parts row by row or batch by batch, and hold only the columns you need. Loading a whole part to count rows is the quickest way to turn a healthy download into a failed job on your side.
Media outputs are worse for this than tabular ones. Write them straight to storage and verify from the file, not from a buffer.
What success looks like
Every file the manifest binds is on disk, at the declared byte count, matching its declared digest. Your row totals match the manifest totals across all four output paths.
At that point the bundle is yours and it is final. Accepted work does not change afterwards.
If verification fails
A digest mismatch or a short file means the transfer, not the run. Discard the file and download that part again under the same authority.
If the same file fails twice, stop and raise it with support with the job reference and the failing path. Never send a payload dump, a key or a signed link — support does not need them.
If the manifest itself is absent, the run is not terminal. Check the job state first, then read partial results with cursors, and confirm the shape against the result bundle layout.