Skip to content

fix(cli): emit failure JSON when public DataMap store fails#107

Merged
jacderida merged 1 commit into
mainfrom
fix/json-output-on-datamap-store-failure
Jun 5, 2026
Merged

fix(cli): emit failure JSON when public DataMap store fails#107
jacderida merged 1 commit into
mainfrom
fix/json-output-on-datamap-store-failure

Conversation

@jacderida
Copy link
Copy Markdown
Contributor

Problem

ant --json file upload --public prints no JSON at all when the file body uploads successfully but the trailing public DataMap chunk fails to store. The UploadFailureJson emission only covers the DataError::PartialUpload arm of the body upload; the DataMap path bails straight out via ? (handle_file_upload, file.rs).

Harnesses that parse stdout (e.g. the prod uploader service) see exit≠0 with empty stdout and record 0/0 chunks. Observed on PROD-UL-01 (2026-06-04): 500/500 body chunks stored and paid for, DataMap PUT rejected by 4/7 close-group nodes (see WithAutonomi/ant-node#127), reported as:

│ 1 │ 2015...mp4 │ 1.94 GB │ partial │ 0/0 │ 0 │ 44m 51.6s │

That hides that the body chunks are on the network and paid for — the upload is one 324-byte chunk away from being retrievable, and a DataMap-only retry would be far cheaper than a full re-upload.

Fix

Emit an UploadFailureJson before bailing, matching the PartialUpload arm:

{"error":"datamap_store_failed","total_chunks":501,"chunks_stored":500,"chunks_failed":1,"reason":"failed to store public DataMap: ..."}

Existing consumers need no changes — e.g. the prod uploader's classifier already keys off the error field and reads chunks_stored/reason from the same object.

cargo check -p ant-cli and clippy clean.

Companion PR (root cause of the DataMap rejection itself): WithAutonomi/ant-node#127.

🤖 Generated with Claude Code

`ant --json file upload --public` printed no JSON at all when the file
body uploaded fine but the trailing public DataMap chunk failed to
store: the UploadFailureJson emission only covered the PartialUpload
arm of the body upload, and the DataMap path bailed straight out via
`?`. Harnesses parsing stdout (e.g. the prod uploader service) saw
exit!=0 with empty stdout and recorded 0/0 chunks — hiding that the
body chunks were stored and paid for, and that the upload is one small
chunk away from being retrievable (observed on PROD-UL-01, 2026-06-04:
500/500 body chunks stored, DataMap PUT rejected, reported as 0/0).

Emit an UploadFailureJson (error: "datamap_store_failed", with the real
chunks_stored / total_chunks and the DataMap error as reason) before
bailing, matching the PartialUpload arm.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Copy link
Copy Markdown

@dirvine dirvine left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the diff locally. This is a small, targeted fix and the JSON failure path now mirrors the existing partial-upload reporting contract for the DataMap-only failure case. Counts look correct: body chunks remain counted as stored and the public DataMap is reported as the single failed chunk.\n\nLocal verification passed:\n- cargo check -p ant-cli\n- cargo clippy -p ant-cli --all-targets -- -D warnings\n- cargo test -p ant-cli\n\nCI is partly still pending, so wait for the remaining build/E2E/Merkle jobs before merging.

@jacderida jacderida merged commit 99a510d into main Jun 5, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants