Repository navigation
fix(api): return correct status codes for invalid and unreachable downloads - #5676
Merged
Merged
Conversation
…nloads - reject the all-zero address on GET /chunks and GET and HEAD /bytes with 400 instead of a 500 or a slow 503 from the network lookup - map ACT history lookups that fail with not found to 404 and with no usable peer to 503, instead of 500 - send application/x-ndjson as the content type of /pins/check, which streams one JSON object per line Document the 503 response on the download endpoints and bump the API version to 8.2.2.
martinconic
requested review from
acud,
akrem-chabchoub,
aloknerurkar,
gacevicljubisa and
sbackend123
October 23, 2026 12:34
sbackend123
reviewed
Oct 25, 2026
- check only the content address part of a /bytes reference, so an encrypted reference with an all-zero address is rejected too - require a 32 byte, non-zero address on GET and HEAD /chunks, so both methods return 400 for the same invalid address - use 32 byte addresses in the existing chunk tests - keep the doc comment next to TestBytesGetHandlerNoPeers
aloknerurkar
approved these changes
Oct 26, 2026
sbackend123
approved these changes
Oct 28, 2026
acud
approved these changes
Oct 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Checklist
Description
The new OpenAPI conformance check (#5673) found download requests that end in a 500 even though nothing is wrong with the node. This PR fixes those, plus a wrong content type on
/pins/check.1. Invalid addresses on
/chunksand/bytesGET /chunks/000…0read chunk failedGET /chunks/<any 64-byte address>read chunk failedHEAD /chunks/000…0GET/HEAD /bytes/000…0GET/HEAD /bytes/<000…0 + decryption key>Retrieval already rejects an all-zero or wrong-length chunk address as invalid, but with a plain error the handlers couldn't recognize, so
/chunksfell through to 500 and/bytessearched the network before giving up. The handlers now reject these upfront:/chunks(GET and HEAD): the address must be 32 bytes and not all zeros (IsValidNonEmpty()), so both methods agree./bytes(GET and HEAD): a reference can also be 64 bytes (content address plus decryption key), so only its content address, the first 32 bytes, is checked for being all zeros.Note that in bee the all-zero address is
swarm.EmptyAddress(32 zero bytes), notswarm.ZeroAddress.2. ACT downloads whose history can't be loaded
When a download carries ACT headers (
Swarm-Act-PublisherandSwarm-Act-History-Address) and the history can't be fetched, the ACT middleware returned 500act download failed. It only recognized the access control package's own errors, while a history that can't be retrieved fails with the usual storage and retrieval errors. These are now mapped the same way the regular download path already does it:act or history entry not foundact history could not be retrieved because no usable peer was availableThis applies to every endpoint behind the ACT middleware (
/bytes,/chunks,/bzz, …). Other errors still return 500.3.
/pins/checkcontent typeThe endpoint streams one JSON object per line (NDJSON) but declared
Content-Type: application/json, so clients that parse the body as a single JSON document fail. It now sendsapplication/x-ndjson. Neither bee-js nor swarm-cli calls this endpoint, so no known client is affected.Tests
New unit tests for all three fixes: invalid addresses on
/chunksand/bytes(GET and HEAD, including 64-byte references), the ACT error mapping on/bytes,/chunksand/bzz, and the/pins/checkcontent type. Each one fails without its fix. To test the ACT errors, the access control mock got aWithDownloadErroroption. Existing tests that used the all-zero address as a "not found" example, or 3-byte chunk addresses, now use realistic 32-byte addresses.I also checked all of the cases above against a testnet node built from this branch.
Open API Spec Version Changes (if applicable)
8.2.1→8.2.2503response, documented onGET /chunks/{address},GET/HEAD /bytes/{address},GET/HEAD /bzz/{address}andGET /bzz/{address}/{path}. These endpoints already returned 503 when no peer was available, but it wasn't documented./pins/checknow documentsapplication/x-ndjson.#5674 bumps to the same
8.2.2, so whichever merges second keeps it. Once #5674 is merged, the/pins/checkexclusion it adds to the Schemathesis run can be removed, since the content type is now correct.Motivation and Context (Optional)
Part of #4974. These came out of the Schemathesis conformance run on the beekeeper cluster and on a testnet node.
Related Issue (Optional)
#4974, related to #5673 and #5674
AI Disclosure