0.3.74: adopt ciris-server v0.5.205 — the read pool, and the SHA pin becomes a tag

[emooreatx]

Adopts ciris-server v0.5.205. Substrate, all transitive through the one pin: persist v42.1.0 → v44.0.0 (across two majors), edge v21.1.0 → v23.0.0 (two majors), verify v15.0.0 → v15.1.0, leviculum v0.25.0+ciris.1 → v0.26.0+ciris.1.

The other half of our own measurement

CIRISStatus#69 → CIRISServer#575 is where this node reported GET /v1/identity going p50 1.1 ms → 780 ms inside a burst at 6.9% duty with zero non-200s. CIRISPersist#829 is where that bottomed out: every read ran inline-sync on the request-serving runtime behind one connection mutex, so two readers serialised no matter how their callers were phased.

v0.5.204 (adopted in 0.3.70) de-phased the colliding loops — the part a scheduler fix can reach. persist v43.1.0, carried by v44, reaches the rest: one writer connection plus a pool of read-only WAL connections, every SQL call and the wait for its connection dispatched off the tokio worker onto the blocking pool.

This node is the two-reader case by construction — the roster walks list_scores over its own corpus while the same runtime serves the status API.

The worker cap from 0.3.73 is re-aimed, by its own evidence

#578 capped worker threads. #577's own table shows ciris-edge-tran flat at 2/2 on both a 32-core and a 4-core host, so the 64 unnamed tokio-rt-worker threads it counted were never edge's workers. What was uncapped is max_blocking_threads — tokio's default 512 per runtime — and the read pool is exactly what makes that pool load-bearing. node_runtime now caps it at 32 with a hard floor of 16, because block_in_place draws its replacement worker from that same pool: starve it and the runtime wedges rather than slows.

We call node_runtime::build and inherit the cap, setting no override. DEPLOY.md §2 is intact — the tuning env var is an upstream escape hatch we do not use, and the default applies unset.

Breaking changes: neither touches us

register_observed_claim now names what a claim PROVED (CIRISEdge#582 — signing a holding claim required holding nothing, so Sybils could vote honest copies into deletion) and BlobChunkSource changed shape. No call site here for either; AvDispatcherError::Congested breaks no exhaustive match of ours. Confirmed by grep and by the compiler.

The SHA pin goes back to a tag

0.3.73 carried #576 + #578 by SHA because this is the node that measured the stalls they fix, and waiting for a release meant the evidence going stale on the box that produced it. That debt is paid in the direction it was promised rather than inherited:

$ git merge-base --is-ancestor 2d9d9fa50b17026642790bc2faadbdf1a47ec41a v0.5.205
YES

Same code, now reproducible from a tag, movable by cargo update -p ciris-server, and safe against a force-push to main.

Verification

• cargo build --release --locked — clean, across both persist majors
• cargo test --locked — 131 passed, 0 failed
• cargo clippy --all-targets --locked -- -D warnings — clean
• cargo fmt --check — clean

🤖 Generated with Claude Code

https://claude.ai/code/session_01HhKY2YZNH2LzNTQVwgjnBh

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.