0.3.57: adopt ciris-server 0.5.194 — and the worker floor is not inherited - #65
Merged
Conversation
…rited The pin moves 0.5.190 → 0.5.194, and one line of this cut is a real code change here rather than a version bump. THE FLOOR HAD TO BE ADOPTED, NOT INHERITED. `#[tokio::main]` sizes a runtime to core count, so on the 2-vCPU canonical this binary got TWO workers — a two-slot budget for the accept loop, replication, the scorer and every request at once. One blocking task and HTTP is unschedulable: the socket stays LISTEN while `Recv-Q` climbs and userspace never calls `accept()`. Measured on that host with one worker pegged at 99.9% and five threads idle (CIRISServer#501, which reproduced on 0.5.192 and was NOT a .193 regression). ciris-status calls `serve_with_adapter`, so it inherits every fix INSIDE the server and NONE of the floor — the floor lives in the runtime each binary builds for itself. That is the same shape the server's own review caught one layer down, where the floor reached `main.rs` and missed the two embedded serve paths. Here it crosses a repo boundary. `ciris_server::node_runtime::build` is the shared builder: floor of 4, never a cap, a deliberate `TOKIO_WORKER_THREADS` still honoured. This node shares the canonical with six other containers, so it is the difference between degrading and disappearing. The other half of #501 IS inherited: boot prime was awaited inline while `read_api_bind` sat ~180 lines below, so time-to-serving scaled with the directory — 11,034 transport_destinations against 748 keys, 33s of boot with the socket bound and nothing accepted. Now spawned and yielding per batch, with `announced_peers` bounded at 30 days. 0.5.193 is insurance rather than a cure here — ciris-status carries no agent — but it takes the occurrence model with it: occurrences are independent by default and nothing here is joined to anything. 0.5.192 decoupled the client version to a tested range; 0.5.191 closed the gate that let CIRISServer#493 ship. Substrate UNCHANGED across all four: edge v18.11.0 / persist v38.6.0 / verify v13.6.1. Every one of these cuts is server-side only. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BSa6L2MEDAXmoJuBVUZNVg
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
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.
0.3.57 — adopt ciris-server 0.5.194
Pin moves 0.5.190 → 0.5.194. Substrate unchanged underneath all four: edge
v18.11.0 / persist v38.6.0 / verify v13.6.1.
The worker floor is NOT inherited, and that is the point of this cut
#[tokio::main]sizes a runtime to core count, so on the 2-vCPU canonical thisbinary got two workers — a two-slot budget for the accept loop, replication,
the scorer and every request at once. One blocking task and HTTP is unschedulable:
the socket stays LISTEN while
Recv-Qclimbs and userspace never callsaccept(). Measured on that host with one worker pegged at 99.9% and fivethreads idle (CIRISServer#501 — which reproduced on 0.5.192 and was not a .193
regression).
ciris-status calls
serve_with_adapter, so it inherits every fix inside theserver and none of the floor — the floor lives in the runtime each binary
builds for itself.
That is the same shape the server's own review caught one layer down, where the
floor reached
main.rsand missed the two embedded serve paths. Here it crosses arepo boundary. Now:
Floor of 4, never a cap, and a deliberate
TOKIO_WORKER_THREADSstill honoured.This node shares the canonical with six other containers, so it is the difference
between degrading and disappearing.
What is inherited
read_api_bindsat ~180 lines below, so time-to-serving scaled with thedirectory — 11,034
transport_destinationsagainst 748 keys, 33s of boot withthe socket bound and nothing accepted. Now spawned, yielding per batch.
announced_peersbounded at 30 days, capped per pass.transport_destinationsdeliberately not pruned: all 11,034 rows areassertions rather than observations, and pruning would strand a node on a
canonical route it cannot relearn.
(ciris-status carries no agent), but it takes the occurrence model with it:
occurrences are independent by default and nothing here is joined to anything.
0.5.191 closed the gate that let CIRISServer#493 ship.
Verification
110 tests pass, clippy
--all-targetsclean, lock resolvesciris-server 0.5.194at the merged commit.
🤖 Generated with Claude Code
https://claude.ai/code/session_01BSa6L2MEDAXmoJuBVUZNVg