[kiwidream]

Fixes the two independent failures on #780's CI (run 40351435557). #780 only adds a Markdown file, so both failures come from main itself. The other two red checks, Prove every Rust PRISM gated test executed and Lint, compile, and test, only report that shard 3 and the audit job failed.

Check	Cause	Fix
Dependency audit	RUSTSEC-2026-0386, published after #778 merged: tokio 1.53.1's safe AsyncFd constructors violate I/O safety. Every PR into main fails this check now.	tokio 1.53.1 → 1.53.3, its first fixed patch, in the root and fuzz lockfiles
PRISM PostgreSQL shard 3	b574_ack_cap::a_captured_proof_is_answered_at_the_cap_and_credited_after_its_landing: proxy connection task failed: Connection reset by peer (os error 104)	Run each disposition poll in its own task, so the ack bound never cancels it partway through a checkout

1. tokio for RUSTSEC-2026-0386

As #777 did for the TLS advisories, this moves tokio to its first fixed patch release. Nothing in the workspace uses AsyncFd. Only tokio's version and checksum change: cargo update -p tokio --precise 1.53.3 also moved the windows-sys edges of four unrelated crates (errno, quinn-udp, rustix, tempfile) from 0.61.2 to 0.52.0, so the edit leaves those alone. Both lockfiles pass cargo metadata --locked.

2. The b574_ack_cap connection reset

The test passed, but the ledger execution proxy then failed the run while the fixture was closing. Its client socket had received a TCP reset. deferred_share_disposition wrapped each poll's checkout and SQL in timeout_at(bound, …). Sometimes the bound expired while the checkout was still running:

• during the pool's before_acquire ping, which runs once a connection has been idle for 100 ms and is the likely case, since the loop polls every 50 ms across several pooled connections, or
• during a new connection's setup.

When that happened, SQLx dropped the raw connection with the reply still unread. The kernel then answered with a reset, which the proxy treats as an error by design (#440). The same drop also costs production a healthy pooled connection, and PostgreSQL logs it as a client reset.

The poll now runs in its own task, as the duplicate probe and enqueue already do (#574), and only the wait for it is bounded. Answers, phases and block_proof_ack_capped_total are unchanged. A poll that is still running at the bound, or when the submission is cancelled, finishes on its own and returns its connection. database_pool_acquire_seconds therefore records that checkout when it ends, not as a cancelled failure at the bound. Two acquire tests asserted the old cancellation and now assert this. docs/prism-pool-acquire-metrics.md is updated to match.

Evidence

• This failure has not appeared in any failed PostgreSQL shard log since 2026-10-01 (52 scanned). Locally the test passed 100 of 100 sequential runs, so it is a rare scheduling race.
• To make the race reproducible, a local-only diagnostic patch (not committed) leaves the checkout ping's reply unread for 20 ms. With it, unfixed main failed 26 of 30 runs, every time with exactly the CI error. With this fix and the same patch, it passed 30 of 30.

Checked locally

• cargo deny --locked check: advisories, bans, licenses and sources ok. As a control, origin/main fails the advisories check with RUSTSEC-2026-0386.
• cargo fmt --all -- --check; cargo clippy --locked --workspace --all-targets -- -D warnings.
• python3 scripts/check_prism_pool_acquires.py with its unit tests, and python3 scripts/check_toolchain_pin.py.
• coordinator::miner_submit::acquire_tests: 10 of 10 against PostgreSQL 16.
• The full cargo test --locked -p qbit-prism-server against PostgreSQL 16: 2,112 passed. The only failure was public_database_config, caused by my cluster's trust-all pg_hba.conf; it passes under the SCRAM pg_hba.conf that test/prism-native-tests.sh writes. The qbitd tests skipped because this host has no qbitd.
• After the local review's fix: the lib suite 703 of 703 (at 4 threads; at 6, four unrelated lock-timeout and deadline tests failed and then passed on their own), b574_ack_cap 22 of 22, b478_capture_overpay 29 of 29, lost_race_pin 8 of 8, compact_runtime_e2e 35 of 35.

Review notes

• A local /code-review medium found one thing worth fixing, and it is fixed here. The 3.x.x: a block found on the current tip is dropped when the payout revision moves between its submit check and its append's revision fence (#478 capture gap) #657 capture path can reach the loop with its deadline already passed, and now starts no poll there; the old code started one there that could only be cut off.
• Trade-off: a poll still waiting for a pool slot at the deadline now keeps its place until it gets a slot or acquire_timeout runs out. It then runs one indexed SELECT whose result is thrown away. This is at most one poll per capped block-bearing submission, the same trade 3.x.x: cap a captured block proof's acknowledgement wait at the share-commit timeout (follow-up to #562) #574 made for the probe and enqueue.
• Out of scope: any other ledger checkout cancelled partway through can drop a connection the same way. That is SQLx's behaviour when an acquire is cancelled. This PR fixes only the path behind the failing test.

3.x.x and 3.0.x have the same tokio 1.53.1 pin and the same poll code, so they need the same changes.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-26T17:01:12.246898Z	2608df7	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[qbit-reviewer]

Reviewed at 2608df7: 0 findings shared privately with maintainers.