backlog: file #1357 -- the connscale FD probe cannot see a multi-process engine - #601
Open
wshallwshall wants to merge 1 commit into
Open
backlog: file #1357 -- the connscale FD probe cannot see a multi-process engine#601wshallwshall wants to merge 1 commit into
wshallwshall wants to merge 1 commit into
Conversation
…ess engine A single probe tick costs longer than the entire measurement window, so the PID set is resolved once per sweep step and never re-resolved. Measured: one tick costs 1419-1848 ms against hold_seconds = 1.5. _RESOLVE_EVERY_TICKS = 8 is therefore unreachable by construction -- not a badly-chosen constant, one the window cannot afford at any cadence. Its own comment reasons at "the runner's poll cadence", which this profile does not have. The consequence is the reason it is worth a row: nothing on this project can currently measure the resource posture of a multi-process engine. That is what holds #1278, rather than any test failure. The item carries the per-tick trace, because the summary number hides the finding. The walk's PID set varies 2, 3, 8, 50 across CONSECUTIVE TICKS OF ONE RUN and handles track it almost linearly -- so handles_peak measures what the walk caught, not what the engine holds. Four things it is not, each checked rather than assumed: not probe degradation (zero degraded ticks, and degradation makes that SLO pass vacuously so it cannot red it); not the #220 PID-set gate (that predicate is on the CPU path, the FD gauge is a plain max); not PR 598 (grepped against its diff -- and its test constructs FdSampler(resolve_every=1) explicitly, so the fixed guard PASSES against this defect, proving re-resolution works when asked while production never asks); and not a loose SLO (a red needs a collapse below 75 percent). It also deliberately does NOT carry a resource figure. Forcing per-tick resolve produced ~3745 handles against a ~385 baseline, which would be ~312 per worker child. That number is withdrawn and the item says so in terms, because the trace shows the denominator is not stable enough to divide by. Leaving a withdrawn figure quotable from a backlog row is how it comes back as a fact. Number allocated with scripts/coord/alloc.ps1 and the row added in the same commit. backlog_status_check passes: 600 items, each declaring exactly one status. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
wshallwshall
enabled auto-merge (squash)
August 25, 2026 21:32
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
1 participant
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.
Filed and verified by Builder 1: a single connscale probe tick costs 1419-1848ms against
`hold_seconds = 1.5`, so `_RESOLVE_EVERY_TICKS = 8` (probe.py:60) is unreachable by construction --
not a badly-chosen constant, one the measurement window cannot afford at any cadence. The PID set is
resolved once per sweep step and never re-resolved, so a multi-process engine's worker children are
invisible to the FD gauge.
Measured, not argued: the walk's PID set swings 2, 3, 8, 50 across consecutive ticks of one run, with
handles tracking it almost linearly -- `handles_peak` measures how many processes the walk happened
to catch, not the engine's footprint. Surfaces as a controlled A/B: `test_the_fd_and_empty_claim_
curves_are_monotonic_in_n` fails 4 runs in 5 under `[sandbox].mode=subprocess`, 0 in 5 under `off`
(Fisher exact p=0.0476).
Explicitly distinguished from PR 598 (already landed): that fix is about re-resolution producing the
wrong verdict when it runs; this is re-resolution not running at all. 598's own test constructs
`FdSampler(resolve_every=1)` explicitly, so its green does not cover this defect.
Deliberately carries no resource-cost figure -- an earlier ~312-handles-per-child estimate is
withdrawn in the row itself, since the trace shows the denominator isn't stable enough to divide by.
This is why BACKLOG #1278 is held on a costed-resource question with no credible number yet, not on
a test failure.
Number allocated properly (scripts/coord/alloc.ps1) before filing. Docs-only, no code changes, no
tests to run -- verified the ledger gate passes (600 items, each declaring exactly one status).
Co-Authored-By: Claude Opus 5 noreply@anthropic.com