[grumbach]

A node that refuses a fetch at admission now tells the requester Busy at once, when the request asked for it and the reply fits within the responder's limits, instead of staying silent. That silence cost every refused requester a 30 s wait and charged the refusing holder a connection-timeout trust event it had not earned.

The problem. A fetch responder admits two outstanding requests per requesting peer and twelve overall. It refuses the rest at admission (Fetch response dropped at admission) and sends nothing back. Then:

• the requester waits its whole fetch timeout (30 s) before trying the next holder;
• saorsa-core records ConnectionTimeout against the holder, which only did what its limits say;
• the requester learns nothing, so it keeps starting new fetches on the same holder.

#252's description reports, from the responders' cumulative admission counters, that 36.6% of inbound fetch requests on 0.21.0 and 44.3% on 0.22.0 were refused this way, and that the WARN line counted 3.38M refusals in the 25-hour window containing the 2026-10-11 join wave of 177 new nodes. #252 keeps a requester within each answering holder's share, which removes most per-peer over-share. Refusals remain for a busy reply to answer: a share still held by requests the requester already gave up on (which #252's description leaves to a busy reply), a twelve-slot pool full of other peers' requests, and a holder #252 currently counts as silent, which it may send requests past the share until an answer clears the mark or the mark expires and the holder is probed under the share again. Older requesters stay on the old silence until they upgrade.

The change.

• Wire. A requester that understands busy replies appends a 5-byte capability trailer (antf and a flags byte) after the encoded FetchRequest. FetchRequest's own layout is unchanged. Older nodes decode with postcard's from_bytes, which ignores trailing bytes, so they read the key and keep refusing silently. FetchResponse::Busy { key } is appended after the existing variants, whose discriminants are unchanged. It is sent only in answer to a request carrying the trailer, so an older requester never receives it.

• Responder. Every message is signed (about 5 KiB with the ML-DSA-65 key and signature), so busy replies are bounded:

  • 48 send permits;
  • per peer, two back to back, then one a second, with at most two in flight;
  • overall, 32 back to back, then 16 a second (about 85 KiB/s sustained);
  • a 2 s send deadline, and the send races shutdown.

  Anything outside those bounds is the old silence. The refusal WARN line keeps its text and counters and gains capability and reply fields.

• Requester. The fetch worker's requests ask for busy replies. A Busy for any other key than the one requested is charged as malformed, like every key mismatch. A Busy for the requested key carries no trust event while its holder is within its neutral allowance: eight busy answers in a row to this requester, counted across all keys, since the holder last served it. Past the allowance, each further busy answer is handled as the silent refusal it replaces: the attempt holds its slot until its fetch timeout runs out, never longer however late the answer came, and then the holder is charged one unit-weight ApplicationFailure, which saorsa-core scores the same as the ConnectionTimeout silence earned. Only serving this requester once restores the allowance; time does not. Within the allowance, the attempt waits 5-10 s with jitter, never past its own fetch timeout, still holding its fetch slot, then ends as a source failure. So the queue moves on to the next holder exactly as after a timeout, and a busy answer cannot become a fast retry loop. While its cooldown runs, fix(replication): keep fetches within each answering holder's admission share #252's per-source scheduler puts the busy holder after every other free holder when starting or retrying keys, and still before a silent one, so a holder is never withheld. The cooldown is 1, 2, 4, then 8 times the full jittered wait drawn for that answer, even when the attempt's deadline cut the sleep short, capped at 60 s, and a later busy answer never shortens a running cooldown. Serving once resets the multiplier, and so do 10 minutes without a busy answer, which leave the allowance count as it was. The table holds 4096 holders, and a holder leaves it only by serving. When it is full, a holder it does not track yet is charged for each busy answer, as for silence, and is not put last.

Built on #252. This branch carries #252's commit (81325f4, #252's head on main a5bccf0, and its earlier forms 33ec231 and 447c000) and merges after it. Until #252 merges, the diff below includes #252; this PR's own changes are its commits other than those three. In the combined build:

• fix(replication): keep fetches within each answering holder's admission share #252's scheduler reads the busy tracker, and puts a cooling holder after every other free holder;
• a busy answer counts as an answer for fix(replication): keep fetches within each answering holder's admission share #252's silent-source tracking, as every answer does;
• a busy wait keeps its attempt in flight, counted against the holder's per-source share.

What it does not do.

• Refusals beyond the responder's busy-reply limits are still silent and still charged.
• A holder that never serves gets eight free busy answers in a row per requester, then pays for each further refusal what silence cost. A holder that serves one fetch in nine is never charged; bounding selective service more tightly would need a service audit, which this does not add.
• The count does not decay with time. An honest holder that, over any length of time, answers one requester busy nine times without serving it once in between is charged for the ninth, as silence would have charged every one.
• The count lives in memory, so a requester restart starts every holder afresh: at most eight free busy answers per holder per run of the requester. Keeping it across restarts would need a new on-disk format.
• There is no runtime switch. Capability is per request, so mixed versions are safe, and undoing it means a release without it.

Linear issue

Closes V2-1514

Risk tier

• T0 — docs / tooling / CI / pure UX-output. Repo CI only.
• T1 — client-only, no network-facing behavior change. CI + prod compat smoke.
• T2 — node/client logic with behavioral surface, no protocol/format/economics change. Dev testnet + ADR.
• T3 — protocol / storage format / payments / routing. T2 evidence + adversarial testing.

Compatibility

• Wire: additive and version-gated per request. New FetchResponse::Busy variant, appended, and an optional 5-byte capability trailer after a FetchRequest message. Older nodes ignore the trailer and are never sent Busy. Pinned by tests that decode with mirrors of the previous types.
• Storage: none.
• API: breaking for crate users. FetchRequest gains a public busy_reply field (not serialized), FetchResponse gains a variant, and there is a new public replication::fetch_busy module. Also new and public: protocol::{FETCH_CAPABILITY_MAGIC, FETCH_CAPABILITY_BUSY_REPLY}. Additive test-only hooks under test-utils, beyond fix(replication): keep fetches within each answering holder's admission share #252's: ReplicationEngine::{fetch_source_cooling_for_test, fetch_source_last_busy_for_test, fetch_source_unserved_busy_for_test, fetch_admitted_for_test, fetch_pool_full_refusals_for_test, turn_off_fetch_busy_replies_for_test}.

Semver impact

• breaking
• feature
• fix

Test evidence

The combined build is #252 with this PR on top. Its current head, b0cef92, is #252 at 81325f4 on main a5bccf0 (#258 and the 0.23.1 release included). It is the previous head 1ba41d8 (#252 at 33ec231 on main 2598bcf) plus only main's changes to Cargo.toml and Cargo.lock, which move saorsa-core to 0.29.2, ant-protocol to 5.0.1 and saorsa-transport to 0.38.2 from crates.io, and rustls-webpki and webpki-root-certs to fixed versions. The gates below and three real-node runs were made on b0cef92, and four more real-node runs on 1ba41d8. The other real-node runs in the table were made on 20eddd0, the same code on #252 at 447c000 and main b0e29c3, before #250. The table also has control runs of #252 alone, and the paragraph after it earlier runs without #252.

Dev testnet: not run yet. #252 (T2) and this PR (T3) both need it before merge; one join-wave run of this head covers both.

Real nodes. tests/e2e/fetch_busy_ab.rs is opt-in: ANT_FETCH_BUSY_AB=1 cargo test --test e2e --features test-utils fetch_busy_ab -- --nocapture --test-threads=1. 20 requesters, each within its two-request share; the first of five holders keeps its 12-slot pool full for 2 s, the refusal case left after #252 (28 refusals in every run).

build	time to fetch all 40 chunks	requesters charging the five holders
#252 alone (447c000, plus the file's two test-only counters)	60.4 s, 60.5 s, 60.8 s	14, 8, then 0 to 7
#252 + this PR (b0cef92)	10.1 s, 10.2 s, 9.8 s	none
#252 + this PR (1ba41d8)	10.3 s, 10.5 s, 18.8 s, 9.6 s	none
#252 + this PR (20eddd0, before #250)	10.2 s, 10.0 s, 10.0 s, 10.0 s	none

One more run of #252 alone stopped before measuring, at the test's check that every key was newly queued (38 of 40). Every measured run fetched every chunk.

Earlier, without #252, on main a6e3388: the same case took 90.3 s in one run on that main, against 9.4 s to 10.5 s in four runs, no holder charged, for this PR alone. A single requester over-asking three holders, the case #252 removes, took 90.2 s, 90.2 s and 90.3 s on that main, and 35.4 s to 39.2 s in six runs for this PR alone; that measurement left the file once #252 made the case impossible.

Raw output

#252 alone  pool run 1: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=60431 requesters_charging_each_holder=[14, 8, 2, 0, 7] trust_lost_per_holder=[1.5987635474790887, 0.8761806998735105, 0.12399958245846532, 0.0, 0.7598691551229271]
#252 alone  pool run 2: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=60456 requesters_charging_each_holder=[14, 8, 6, 5, 6] trust_lost_per_holder=[1.5843052522776773, 0.9304925809719726, 0.4806223379475439, 0.5815579302772491, 0.6435576027717026]
#252 alone  pool run 3: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=60812 requesters_charging_each_holder=[14, 8, 6, 5, 6] trust_lost_per_holder=[1.6276710041265043, 0.9304876107230622, 0.5892427842223408, 0.47293179987213263, 0.6978658171304406]
b0cef926    pool run 1: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=10107 requesters_charging_each_holder=[0, 0, 0, 0, 0] trust_lost_per_holder=[0.0, 0.0, 0.0, 0.0, 0.0]
b0cef926    pool run 2: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=10202 requesters_charging_each_holder=[0, 0, 0, 0, 0] trust_lost_per_holder=[0.0, 0.0, 0.0, 0.0, 0.0]
b0cef926    pool run 3: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=9807 requesters_charging_each_holder=[0, 0, 0, 0, 0] trust_lost_per_holder=[0.0, 0.0, 0.0, 0.0, 0.0]
1ba41d84    pool run 1: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=10256 requesters_charging_each_holder=[0, 0, 0, 0, 0] trust_lost_per_holder=[0.0, 0.0, 0.0, 0.0, 0.0]
1ba41d84    pool run 2: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=10491 requesters_charging_each_holder=[0, 0, 0, 0, 0] trust_lost_per_holder=[0.0, 0.0, 0.0, 0.0, 0.0]
1ba41d84    pool run 3: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=18802 requesters_charging_each_holder=[0, 0, 0, 0, 0] trust_lost_per_holder=[0.0, 0.0, 0.0, 0.0, 0.0]
1ba41d84    pool run 4: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=9629 requesters_charging_each_holder=[0, 0, 0, 0, 0] trust_lost_per_holder=[0.0, 0.0, 0.0, 0.0, 0.0]
20eddd04    pool run 1: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=10237 requesters_charging_each_holder=[0, 0, 0, 0, 0] trust_lost_per_holder=[0.0, 0.0, 0.0, 0.0, 0.0]
20eddd04    pool run 2: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=10045 requesters_charging_each_holder=[0, 0, 0, 0, 0] trust_lost_per_holder=[0.0, 0.0, 0.0, 0.0, 0.0]
20eddd04    pool run 3: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=10027 requesters_charging_each_holder=[0, 0, 0, 0, 0] trust_lost_per_holder=[0.0, 0.0, 0.0, 0.0, 0.0]
20eddd04    pool run 4: FETCH_BUSY_AB_POOL requesters=20 keys=40 enqueued=40 stored=40 refused_while_full=28 elapsed_ms=10019 requesters_charging_each_holder=[0, 0, 0, 0, 0] trust_lost_per_holder=[0.0, 0.0, 0.0, 0.0, 0.0]

End to end (tests/e2e/fetch_busy_reply.rs), deterministic through a test-only fetch serve gate, the same one #252 adds:

• a refused request that asks is told Busy at once, and one that does not ask is refused silently;
• the requester's own fetch worker, refused because its two-request share at the holder is full:
  • records the holder as cooling;
  • holds the attempt for at least the 5 s minimum wait before giving the key up;
  • never lowers the holder's trust;
• a holder that keeps refusing the requester's fetch worker, one new key after another:
  • costs nothing for eight busy answers;
  • on the ninth, the attempt holds its slot until its fetch timeout runs out, with no charge meanwhile, and the holder is charged as it ends;
  • once the holder serves the worker a chunk, its count is cleared;
• fix(replication): keep fetches within each answering holder's admission share #252's two per-source share tests pass on this head. Its silent-holder test turns off that holder's busy replies with a test-only switch, so it still models a holder that answers nothing: one that answers busy is answering, and stays under fix(replication): keep fetches within each answering holder's admission share #252's cap.

Unit tests on top of #252 (21 new in fetch_busy, 9 in protocol, 2 in mod, 2 in scheduling):

• mirrors of the previous wire types: both directions decode, and an older requester cannot decode Busy;
• trailer edge cases;
• limiter:
  • burst, refill and the global cap;
  • no spend on a denial;
  • the in-flight limit;
  • the table bound;
• the busy wait's bounds, and a busy answer, however late, never holding the slot past the fetch timeout;
• the tracker:
  • cooldown and escalation;
  • not shortened by a later busy answer;
  • reset, and a new busy spell after a quiet one;
• the neutral allowance:
  • a sole holder answering busy every 5 s for over an hour without serving is charged for every answer after the eighth;
  • answers that arrive together each count;
  • serving once between spells of eight is never charged;
  • serving restores the allowance; another holder serving and time alone do not;
  • a full table forgets no count, charges a newcomer instead, and makes room once a holder serves;
• fix(replication): keep fetches within each answering holder's admission share #252's dispatch and retry pass over a cooling holder for another free one, still take it before a silent one, and never withhold it;
• busy replies are not counted as served bytes.

Simulation. A local, unpublished discrete-event model of the 177-node join wave and 24 edge cases informed the design, including the 5-10 s wait. Its source and raw output are not part of this PR, so its results are not offered as review evidence.

Gates run locally, on b0cef92:

• cargo fmt --all -- --check
• cargo clippy --all-targets --all-features -- -D warnings, on stable and on Rust 1.99 (CI's toolchain), and cargo +1.96.1 clippy --locked --lib --all-features -- -D warnings
• cargo clippy -- -D warnings
• RUSTDOCFLAGS="--deny=warnings" cargo doc --no-deps
• cargo test --lib --features test-utils: 1271 passed
• RUSTFLAGS="-D warnings" cargo check --lib --no-default-features and RUSTFLAGS="-D warnings" cargo test --lib --no-default-features: 1226 passed
• cargo test --test e2e --features test-utils -- --test-threads=1: 125 passed, plus the three live_testnet tests that are ignored on main
• the bounded-queue and bootstrap-stall regression suites (poc_d1_bounded_queues, poc_bootstrap_stall)
• scripts/adr-governance.py against main
• cargo audit: no vulnerabilities; its six allowed warnings all come from main's lockfile, which this PR does not touch

Review. Codex-assisted:

• design: three rounds;

  • round 1 rejected a first design whose retry rotation and expiry charges could storm and punish honest holders;
  • rounds 2 and 3 approved with changes, all made;

• code: five rounds to "No findings", then a fresh full review on 2026-10-16, also "No findings". Its review of the second commit found that a debug line could report a shorter cooldown than the one in force; that is fixed in the same commit, and the commit was then reviewed again with "No findings";

• the neutral allowance (2026-10-20): nine rounds to "No findings", plus five reviews with no history, the last two with "No findings". Fixed along the way:

  • the allowance came back after a quiet spell, or when a full table forgot a holder;
  • a charge could land before the attempt's wait was over;
  • a late busy answer could hold the slot past silence's deadline;
  • several tests could pass without proving what they claimed.

  Two limits were kept and documented: the count lives in memory, and after a cold dial the charge can come up to the dial's time sooner than silence's would. The last two of the reviews with no history treated both as out of scope;

• building on fix(replication): keep fetches within each answering holder's admission share #252 (2026-10-20): three rounds to "No findings". Fixed along the way: the over-share A/B measurement, which fix(replication): keep fetches within each answering holder's admission share #252 made unable to produce a busy reply, was removed, and the A/B file's description of its test hooks was corrected;

• this description and the ADR: reviewed separately until no findings remained.

New dependency

none

ADR

https://github.com/grumbach/ant-node/blob/fetch-busy-reply/docs/adr/ADR-0025-fetch-busy-reply.md

Mitigation / rollback

Ship a release without it; capability is negotiated per request, so nodes on either side of a mixed fleet keep working.

[dirvine]

Provisional review — changes recommended

Reviewed WithAutonomi/ant-node@6abba5a79a7f04be40e11aa12c4a638148989ace against 8d25f0c311a964ba8f440fe4d0b9359b6294dfc8. All 11 changed files were inspected. This is a review of that standalone head, not a build of #253 combined with #252/current main.

Material concern: bound the trust-neutral Busy exemption

src/replication/mod.rs:9637–9672 treats every matching-key Busy as trust-neutral. SourceBusyTracker (src/replication/fetch_busy.rs:301–410) adds a bounded cooldown, but only changes preference: it still selects the first holder when every candidate is cooling, including a sole holder. There is no per-source/path exhaustion transition.

A holder can retain the data, answer storage audits, and answer replication fetches with correctly signed Busy indefinitely. Authentication proves who sent the answer, not that the sender is genuinely overloaded. Each fetch fails over after 5–10 seconds, but repeated non-service never reaches normal fetch accountability. Before this new response, a response timeout reaches ConnectionTimeout in the pinned saorsa-core 0.29.0 (network.rs:1300–1319); a valid NotFound reaches ApplicationFailure in ant-node. Thus this is a new neutral branch, not merely inherited silence.

I exercised the actual public tracker in a reviewer-only Rust integration probe. After 1,000 Busy answers across 5,000 seconds of simulated time, with no service, the same sole holder remained eligible on every selection. The probe passed and was removed from the checkout afterwards. This proves the scheduler has no exhaustion bound; it is not a live malicious-peer or audit experiment. The trust effect follows from the production Busy branch above.

The minimum safety change is a bounded peer/path-level allowance for neutral overload claims, with a defined accountability outcome after exhaustion and recovery tied to cooperative responses on the same path. A per-key retry limit or a longer cooldown alone does not cover repeated claims across keys. Add a regression for repeated valid Busy across multiple keys, alongside the existing honest-transient-overload test. ADR-0025 explicitly defers a service-audit solution; if indefinite neutrality is intentional, it needs an explicit maintainer security decision. I am not treating that trade-off as already accepted.

Publication and verification gates — separate from the concern above

• #252 is now merged. This standalone head uses saorsa-core 0.29.0; current main a6e3388e79d0907ef678bcb6ec0fcaa12822e148 uses 0.29.1. The PR description requires integration with #252 and says that combined build has not been measured. GitHub currently reports MERGEABLE, so I am not claiming a current merge conflict. Update against main and rerun the share/cooldown/retry and Busy E2E checks on the resulting head. No combined-build claim is made here.
• No dev-testnet smoke was run by me. The PR classifies this as T3 and explicitly says dev-testnet evidence is still required before merge.
• Security Audit is red for four RustSec advisories in rustls 0.23.45, fixed upstream in >=0.23.46: RUSTSEC-2026-0346, -0347, -0348 and -0349. Cargo.toml and Cargo.lock are unchanged by this PR; the frozen base and head have the identical lockfile blob. This is an inherited dependency/CI gate, not a new Busy regression. Exact failing job.

Checks I ran on the exact head

Runtime: macOS, rustc/cargo 1.96.0; --locked, test-utils, isolated Cargo target directory.

• cargo test --locked --lib --features test-utils -- --test-threads=1: 1,215 passed. The separately run replication subset also passed, 669 tests; it is included in the library total, not additional coverage.
• cargo test --locked --test e2e --features test-utils fetch_busy_reply:: -- --nocapture --test-threads=1: 2 passed. These cover capability-gated refusal and the requester's neutral Busy handling.
• An attempted additional filter, fetch_busy_ab::fetch_busy_ab_global_pool_full, matched zero tests. It is excluded from the pass counts; it provides no extra global-pool evidence.
• Opt-in fetch_busy_ab_pool, isolated rerun: 40/40 chunks stored, 26 refusals observed, measured storage interval 10.252 s, zero measured trust loss at all five holders. The whole test took 52.45 s. An earlier run concurrent with other tests also stored 40/40, but its storage interval was 39.784 s (101.03 s for the whole test), with trust loss at all five holders. I do not attribute that difference to a code regression; it shows that the load measurement depends on the run conditions.
• Reviewer-only repeated-Busy tracker probe: 1 passed, as described above.
• cargo fmt --check and exact base-to-head git diff --check: passed. The tracked checkout is unchanged.
• GitHub: 23 checks successful; 1 failed, the inherited Security Audit above. These are CI results, distinct from my local runs. The complete live-network/dev-testnet suite was not run.

Panel coverage, dissent and status

4/6 reviewed — partial panel, two of three named models. GLM 5.3/OpenRouter and local Qwen 3.8 each completed correctness/evidence and adversarial reviews. Both DS4 roles timed out in the 120-second model-lock queue; each received its one same-model narrowed retry and timed out again. No substitute model was counted.

GLM found no merge-blocking code defect and considered the documented cooldown policy acceptable. Qwen recommended changes, but its alleged GCRA fencepost/overflow, responder-versus-requester pool exhaustion and detached-send leak did not survive source/test checks: the fixed-time burst tests pass, duration multiplication saturates and is capped, the cited limits belong to responders, and Busy sends have owned RAII grants plus a two-second timeout. I have not repeated those as findings.

The persistent-neutrality concern above is my source- and probe-backed adjudication against the existing overload-accountability review criterion, not panel consensus. Focused GLM/Qwen reconciliation attempts also timed out in their model-lock queues. The material design disagreement therefore remains unresolved. Missing DS4 coverage alone would not prevent a formal verdict, but that unresolved disagreement does: this is a provisional COMMENT, not APPROVE or REQUEST_CHANGES. A human maintainer can decide the security trade-off and submit the formal review. No merge, branch update or deployment was performed.

[dirvine]

Re-review — Busy accountability concern resolved; merge gates remain

Reviewed WithAutonomi/ant-node@a5490a9368693439e3743394bd001f6e628a747b against 8d25f0c311a964ba8f440fe4d0b9359b6294dfc8. This supersedes the Busy-accountability finding in my previous review, not its historical test results. I found no new confirmed source defect in the revised accountability path. This is not merge or release approval.

What is now fixed

• src/replication/fetch_busy.rs:68–87, 410–453: a source gets eight neutral Busy answers across keys since last serving this requester. The ninth and every later answer are charged. Cooldown expiry or silence does not clear unserved; it saturates rather than wrapping. A full 4,096-source table does not evict debt: an untracked source then gets no neutral allowance.
• src/replication/mod.rs:9648–9703 and fetch_busy.rs:167–184: an over-budget answer holds its slot until the attempt's fetch deadline, then awaits one ApplicationFailure(REPLICATION_TRUST_WEIGHT) event, with weight 1.0. This is not an immediate penalty per reply. The deadline is measured from the attempt start; after a cold dial it can precede the old transport response-timeout deadline by the dial duration, as the source documents.
• src/replication/mod.rs:9536–9580: the source's record clears only after the response supplies the expected key and passes size and content-address checks. A locally rejected store or lapsed responsibility after receiving valid bytes does not make that remote service non-cooperation. Already-held and invalid-data exits do not manufacture service. Local shutdown can cancel an uncharged pending fetch; the tracked task otherwise retains its charge when the outer worker awaiter is dropped.

The new real-node regression a_holder_that_keeps_answering_busy_is_charged_past_its_allowance passed: it spends the allowance across different keys, checks no trust loss within it, checks no early charge on the next attempt, then observes a charge and verifies that later valid service clears the record. The previous always-Busy concern is therefore addressed by code and an exercised regression, not merely by a cooldown.

Verified locally at this exact head

macOS arm64, rustc 1.96.0, isolated CARGO_TARGET_DIR; no tracked review edits:

• cargo test --locked --lib --features test-utils -- --test-threads=1: 1,221 passed, including the 22 Busy unit tests (not 22 additional unique tests).
• cargo test --locked --test e2e --features test-utils fetch_busy_reply:: -- --nocapture --test-threads=1: 3 passed.
• Opt-in pool regression (ANT_FETCH_BUSY_AB=1, exact fetch_busy_ab::fetch_busy_ab_pool): 40/40 chunks stored, 20 requesters, 26 full-pool refusals; requester-charge counts [0,0,0,0,0], measured trust loss [0.0,0.0,0.0,0.0,0.0] across five holders. This is a local real-node test, not dev-testnet evidence and not a fresh main-versus-PR comparison.
• Default cargo check --locked --lib and --no-default-features both passed. This resolves the first-pass concern about a test-only gate leaking into production compilation. Format and diff-whitespace checks passed.
• Local cargo clippy --locked --lib --all-features -- -D warnings failed on the two Duration::from_secs(60/600) unit-style lints. The same failures reproduce at the previous PR head 6abba5a with this compiler; this proves they are not introduced by the latest fix, not that they were present at the PR base. CI Clippy is green. A command-line -A control also failed; I do not count it as a passing check.

Gates before merge

1. Integrate with #252 and rerun together. Live #252 is OPEN, head 31f028a2b84013841504783b32ae750842f9c83d. A git merge-tree check against this #253 head reports conflicts in src/replication/mod.rs and docs/adr/README.md. The PR itself requires merging after #252 and says the pair has not been built/measured together. Resolve/rebase, then rerun the combined build, Busy regressions and pool measurements. Main a6e3388e79d0907ef678bcb6ec0fcaa12822e148 text-merges cleanly, but I did not build that combined tree; a clean merge is not integration-test evidence.
2. Supply the required T3 dev-testnet evidence on that integrated build. The PR explicitly says it has not been run. The local loopback harness and the green CI “WebRTC Direct five-node devnet” do not establish that requirement. The ADR is still Proposed; its final acceptance remains a human decision.
3. Clear or explicitly resolve the failing Security Audit under repository policy. At 2026-10-20T07:54:54.310028+00:00, CI shows 21 successful, 1 failed, 2 pending. Security Audit reports seven vulnerabilities: four in rustls 0.23.45 (upgrade recommendation >=0.23.46) and three in zip 2.4.2 (>=9.0.0). Cargo.lock is byte-identical between this head and the frozen PR base, so these are dependency-gate failures, not dependencies changed by this PR. This is not an assessment that every advisory is remotely exploitable in ant-node. Do not describe CI as green while that job fails or other jobs remain pending.

Panel, dissent and limitations

5/6 scoped role reviews completed; 3/3 named models. Partial panel. Missing: deepseek-v4-flash adversarial-risks (output token limit (8192 tokens); no complete verdict).

• z-ai/glm-5.3 / correctness-evidence: APPROVE (narrowed fix scope).
• qwen38-27b / correctness-evidence: APPROVE (narrowed fix scope).
• deepseek-v4-flash / correctness-evidence: APPROVE (narrowed fix scope).
• z-ai/glm-5.3 / adversarial-risks: APPROVE (narrowed fix scope).
• qwen38-27b / adversarial-risks: APPROVE (narrowed fix scope).
• deepseek-v4-flash / adversarial-risks: unavailable after the single same-model retry; output token limit (8192 tokens); no complete verdict.

Input-error disclosure: I incorrectly described the neutral allowance as three in the first and GLM/Qwen narrowed briefs, and named a nonexistent fourth-answer regression. The committed constant and the actual test use eight. Qwen's first-pass adversarial objection correctly identified that discrepancy: it was an error in my brief, not a defect in the PR. Some narrowed responses then repeated my error. I reject their three/fourth threshold statements as evidence; the eight/ninth result above comes from frozen-source inspection and the actual passing E2E. The corrected DS4 retry includes the literal constant and the correction. No additional GLM/Qwen retry is used to obtain agreement.

GLM and Qwen's completed narrowed responses accept the state persistence, fail-closed saturation and delayed charge. First-pass feature-gating uncertainty was resolved by the actual cfg source and two production-feature builds. Retained design watch-outs: the table is requester-memory-only (restart renews each source's allowance); one valid service renews it; saturation conservatively charges newcomers. These are disclosed bounds/trade-offs, not a demonstrated remaining always-Busy escape. Narrowed retry approval covers the accountability fix and connected lifecycle, not a fresh line-by-line review of unchanged trailer/limiter/scheduler code. Missing seats are coverage limits, never code defects. No unqualified full-team consensus is claimed.

Next: finish #252 integration, rerun the gates on the resulting head, provide dev-testnet evidence and resolve the audit/CI status before merge. No merge was performed.

[dirvine]

REQUEST_CHANGES — required integration and T3 validation are missing

Reviewed WithAutonomi/ant-node@a5490a9368693439e3743394bd001f6e628a747b against 8d25f0c311a964ba8f440fe4d0b9359b6294dfc8. This is the formal verdict requested by Anselme in the existing review thread. The source head is unchanged from my verified re-review.

The previous always-Busy finding is closed. Eight neutral Busy answers are allowed across keys; the ninth and subsequent answers incur a delayed unit-weight charge. Time, cooldown and table saturation do not replenish the allowance. I found no new confirmed defect in that standalone accountability path. The changes requested below concern the intended integrated change and its mandatory validation, not a claim that the fixed logic still allows indefinite neutrality.

Required changes before approval

1. Complete the #252 integration and verify the resulting source tree. Location: docs/adr/ADR-0025-fetch-busy-reply.md:135–141, with the integration in src/replication/mod.rs and #252's source selection. The ADR and PR description explicitly require #252 first and say the pair has not been built or measured together. #252 is currently OPEN at 31f028a2b84013841504783b32ae750842f9c83d. The recorded merge-tree check of these exact heads conflicts in src/replication/mod.rs and docs/adr/README.md. Without the per-source share, requesters can still over-share and refusals beyond the reply limits remain silent, as the ADR explains. Minimum change: after #252 lands, rebase/integrate it, resolve the source-choice/cooldown interaction, and rerun the combined build, share/cooldown/retry regressions, Busy E2E tests and real-node pool measurements. Attach results for that exact resulting commit, not separate results for the two PRs.

2. Provide the required T3 dev-testnet evidence for that integrated commit. Location: the PR description's Risk tier and Test evidence / Dev testnet sections. It explicitly says this evidence is required before merge and has not been run. This changes the wire protocol and requester scheduling/trust behaviour. Local loopback tests and CI's WebRTC Direct five-node devnet do not prove the required integrated fetch behaviour. Minimum change: run the approved dev-testnet validation on the rebased build; record the commit/build, configuration, run ID, commands, results and logs in the PR. Include the Busy/share interaction and retained mixed-version compatibility. My review does not authorise deployment.

Current checks — separate dependency gate

At 2026-10-20T08:23:49.786027+00:00, CI has 23 successful, 1 failed, 1 skipped, and no pending checks. Security Audit still fails on the unchanged rustls/zip lockfile dependencies. Resolve it or obtain its disposition under repository policy before merge; I am not presenting inherited advisories as a new defect introduced by this PR. My exact-head runs passed 1,221 library tests, 3 Busy E2E tests, both default/no-default production checks and the 40/40-chunk pool test. The previously disclosed local Duration-unit Clippy failures remain distinct from the green CI Clippy job.

Panel and limitations

5/6 scoped role reviews completed — partial panel. GLM 5.3, Qwen 3.8 and DS4 completed correctness reviews; GLM and Qwen also completed adversarial reviews. DS4's adversarial output hit its 8,192-token limit after its single same-model retry. No further retry or substitute vote was used. The five completed narrowed reviews accept the implementation within their scope; this formal request concerns the still-unmet integration and T3 validation requirements, not a claim that those five models rejected the standalone fix. No full-team consensus is claimed.

The earlier review brief incorrectly said three neutral answers; the committed constant is eight. As disclosed in the linked re-review, GLM/Qwen's resulting three/fourth-answer statements are excluded as evidence. The eight/ninth result is established by exact source, the passing regression and DS4's corrected correctness review. Narrowed reviews do not constitute a fresh full-production review of unchanged wire/limiter/scheduler hunks.

Next: complete the integration and required validation, then request re-review on the resulting head. No merge, branch change or deployment was performed.

[MaidSafe-Hermes]

REQUEST_CHANGES — required T3 dev-testnet evidence is still missing

Reviewed WithAutonomi/ant-node@b0cef9268c046fee546cd8f5a53a0fa0649e1b43 against base a5bccf07e35d5f9d03ba7c5329a90b05525a47b3. The branch now contains #252 at 81325f4077ff899a24b05ab1a1b69fae37f56735; its current PR head is that same commit, although #252 remains open. I found no new confirmed source defect in the Busy reply implementation or its integration with the per-source scheduler.

Required before approval

1. Run and record the required T3 dev-testnet validation on this exact combined head. The PR description says this has not been run and requires one join-wave run of the combined #252+#253 head. The successful CI WebRTC Direct five-node devnet check is useful CI evidence, but it is not the described join-wave dev-testnet run. Add the exact commit, run ID, configuration, commands, results and logs, including the Busy/share interaction and mixed-version compatibility. If the test is run on a newer commit, re-review that head.

This is a missing validation gate, not a claim of a code defect. The previous Busy-accountability finding is resolved: the source retains the eight-answer neutral allowance, charges later answers after the fetch deadline, and does not replenish the allowance on time or tracker-table pressure. The request is limited to the explicitly required T3 evidence.

Checks and review coverage

• GitHub checks at this head: 21 SUCCESS, including Security Audit and WebRTC Direct five-node devnet.
• cargo fmt --all -- --check: passed locally.
• A local focused Cargo test attempt did not finish within the tool's time limit; it is not counted as a pass. The exact-head GitHub Test (ubuntu-latest), Test (macos-latest), and Test (windows-latest) checks are successful.
• 2/2 review seats returned substantive opinions across two scoped evidence bundles: sol-1 (gpt-6.1-sol, xhigh) and glm-1 (z-ai/glm-5.3). GLM approved the code within scope. Sol returned UNCERTAIN where the first bundle lacked integration context; its remaining specific evidence gaps were checked against the frozen source. I found no confirmed defect. This is not panel consensus.

No merge, branch update or deployment was performed.