Summary
When RequestDataHandler removes SeedNodeOnlyInitialDataResponsePayload entries from a GetDataResponse received by a non-seed node, it currently preserves the original isWasTruncated flag.
If truncation was caused solely by the discarded seed-only payloads, the client can repeatedly request the same fallback non-seed peer response without adding the excluded hashes for those discarded entries, making no progress until the request retry limit is reached.
Required changes
Update the GetData response production or filtering flow so the truncation state reflects only payloads retained by the receiving client. Preserve isWasTruncated when at least one retained payload was omitted, but do not retain it when the only omitted entries were seed-node-only payloads that are discarded.
Rationale
The retry mechanism uses truncation to request the remaining data. It must not retry for payloads that a non-seed client is intentionally prohibited from storing.
Affected area
p2p/src/main/java/bisq/network/p2p/peers/getdata/RequestDataHandler.java- GetData response construction/truncation logic in the P2P data-request flow
- Related tests for truncated responses and seed-only initial-data payload filtering
Acceptance criteria
- A non-seed client does not continue retries solely because filtered seed-only payloads caused the original response to be truncated.
- Truncation remains reported when retained payloads were omitted.
- Tests cover both cases above.
Backlinks
Summary
When
RequestDataHandlerremovesSeedNodeOnlyInitialDataResponsePayloadentries from aGetDataResponsereceived by a non-seed node, it currently preserves the originalisWasTruncatedflag.If truncation was caused solely by the discarded seed-only payloads, the client can repeatedly request the same fallback non-seed peer response without adding the excluded hashes for those discarded entries, making no progress until the request retry limit is reached.
Required changes
Update the GetData response production or filtering flow so the truncation state reflects only payloads retained by the receiving client. Preserve
isWasTruncatedwhen at least one retained payload was omitted, but do not retain it when the only omitted entries were seed-node-only payloads that are discarded.Rationale
The retry mechanism uses truncation to request the remaining data. It must not retry for payloads that a non-seed client is intentionally prohibited from storing.
Affected area
p2p/src/main/java/bisq/network/p2p/peers/getdata/RequestDataHandler.javaAcceptance criteria
Backlinks