Compute
Upload a file directly to Compute
Prepare an artifact, transfer it in digested parts, then complete it so the bytes are verified. Recover from an expiry or an interruption without corrupting the upload.
Before you start
Know the file's size, the number of parts you will send, and the data profile the content falls under. Confirm the file fits the ceiling the workflow declares, because that ceiling is smaller than what the transfer layer would accept.
An upload authority is time-bounded. Plan to transfer inside its window rather than hold it open.
The three steps
- Prepare the artifact. You declare size, part count and data profile, and you receive an artifact reference, an upload target, a part size and an expiry.
- Transfer the parts to the target you were given, using the headers you were given.
- Complete the artifact by supplying the manifest digest and the part-root digest.
The artifact moves through its own states as you go: PLANNED, then UPLOAD_AUTHORIZED, UPLOADING, UPLOADED_UNVERIFIED, VERIFIED, and finally ACCEPTED or REJECTED. Only ACCEPTED means a job may reference it. For which ceiling actually binds your file, see how a file reaches Compute.
Send the target and headers unchanged
The prepare step hands you a signed target and the exact headers to send with it. Send them as given.
A rewritten header, a re-encoded path or an added query parameter breaks the signature. The transfer is then refused rather than repaired. If a client library rewrites headers for you, turn that behavior off for this request.
Transfer in parts, and let digests do the ordering
Each part carries its own digest. Parts may travel in parallel, and arrival order does not matter, because the part index decides where each one belongs.
That is also what makes an interrupted transfer safe. An artifact is its own idempotency scope. Re-sending a part with the same identity and the same digest is an exact replay, and it returns the earlier result. Sending different bytes under the same part identity is equivocation, and it is refused rather than accepted quietly.
Complete it, and read the verification
Until you complete the artifact it sits at UPLOADED_UNVERIFIED. Bytes have arrived; nothing has been proven about them.
Completion supplies the manifest digest and the part-root digest. Those are recomputed on receipt and compared. A truncated, reordered or altered transfer fails that comparison and the artifact goes to REJECTED, with a safe reason and a concrete next action.
Never log a signed URL
A signed upload target is temporary bearer authority. Anyone who holds it can write to your artifact until it expires, without any other credential.
So keep it out of shell history, application logs, CI output, screenshots, bug reports and any dump you attach to a support request. Support never asks for one and never needs one.
When you do contact support, give the artifact reference and the request_id from the response envelope. Those identify the transfer without granting anything.
Recovering from an expiry or a failure
If the authority expires before you finish, prepare a new upload authorization for the same artifact and continue. Re-sending identical parts is a replay, so you are not penalized for overlap.
If completion reports a digest mismatch, re-read the source and re-send the parts whose digests disagree. Do not complete again with the same manifest and different bytes; that is the equivocation case, and it refuses.
If the artifact is rejected outright, the reason names what to change. Work from what to do when an input is rejected rather than retrying the same bytes.