0.3.70: adopt ciris-server v0.5.204 — the substrate fix for the scans we measured

[emooreatx]

persist v42.0.0 → v42.1.0, edge v21.0.0 → v21.1.0. Two changes in it are the upstream answers to what this repo has spent a week measuring.

#572 — dimension reads are index-served. V137 indexes V106's generated dimension column, so a prefix filter compiles to a range on it instead of json_extract(attestation_envelope, '$.dimension') LIKE ? evaluated per row. That's the full-table scan behind the roster rebuild (which 0.3.61 dodged by moving to list_scores) and behind every config read.

#570 — per-engine config snapshot cache. That's CIRISServer#557: get_config called live_config_rows per key with no cache, so Config::resolve cost ~50 scans of everything this node had ever authored — and degraded with every observation emitted, since those rows share the attester key the scan seeks on.

Our batching stays

Snapshot (0.3.68) is no longer load-bearing against an uncached substrate, but one fetch per resolve is still one fetch, it's correct either way, and it keeps this consumer honest if the cache is ever invalidated more eagerly than expected. Belt and braces rather than a workaround left lying around.

What this predicts

Stated so it can be checked rather than assumed:

• steady-state pread64 should fall well below the 6,700/s measured on 0.3.68 at 20 minutes uptime (itself down from 13,400/s on 0.3.66)
• the twice-a-minute CPU bursts (~10s at ~30% of a core) should shrink again

And what it does not predict: any change to fordblks. 561 MB of free list against 47.7 MB live survived the config churn being removed, so whatever built it is not these scans.

116 tests, fmt, clippy -D warnings.

🤖 Generated with Claude Code

[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.