Skip to content

0.3.57: adopt ciris-server 0.5.194 — and the worker floor is not inherited - #65

Merged
emooreatx merged 1 commit into
mainfrom
chore/adopt-server-0.5.194
Aug 29, 2026
Merged

0.3.57: adopt ciris-server 0.5.194 — and the worker floor is not inherited#65
emooreatx merged 1 commit into
mainfrom
chore/adopt-server-0.5.194

Conversation

@emooreatx

Copy link
Copy Markdown
Contributor

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 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. Now:

fn main() -> anyhow::Result<()> {
    let runtime = ciris_server::node_runtime::build("ciris-status")?;
    runtime.block_on(async_main())
}

Floor of 4, never a cap, and 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.

What is inherited

  • Boot prime off the critical path. It 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, yielding per batch.
  • announced_peers bounded at 30 days, capped per pass.
    transport_destinations deliberately not pruned: all 11,034 rows are
    assertions rather than observations, and pruning would strand a node on a
    canonical route it cannot relearn.
  • 0.5.193 — the unregistered actor key stops being fatal. Insurance 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 — the client version decoupled to a range tested at both ends.
    0.5.191 closed the gate that let CIRISServer#493 ship.

Verification

110 tests pass, clippy --all-targets clean, lock resolves ciris-server 0.5.194
at the merged commit.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BSa6L2MEDAXmoJuBVUZNVg

…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
@chatgpt-codex-connector

Copy link
Copy Markdown

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.

@emooreatx
emooreatx merged commit f350f84 into main Aug 29, 2026
3 checks passed
@emooreatx
emooreatx deleted the chore/adopt-server-0.5.194 branch August 29, 2026 19:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant