Development record
The load check's stray rule is silent across a load band that itd-2609231434459890's Mechanism, Decision 1 and Grounds claim it covers. A process is a stray only when it is older than the stray limit and its lifetime share of a core is at least 0.9 (NearFullShare, internal/core/machineload/classify.go); the extreme trigger fires only when the one-minute load is strictly above four times the online cores. Busy loops that have run for days each hold their fair share, cores divided by their count, so on 16 cores at the default limits: 17 loops (0.94 of a core each) warn through the stray trigger; 18, 20, 40 or 64 loops, a load between 1.125 and 4 times the cores, each hold under 0.9 of a core and raise no trigger, so the check is silent (no warning, no run-log event); from 65 loops the warning is the extreme trigger's alone, as at the 2026-09-22/23 incident's load of about 440, where the stray count read 0. The share filter applies before the uid split, so the band silences the caller's own loops as well as another account's. The fixture that shows it is TestStrayRuleSilentBand in internal/core/machineload/classify_test.go (TestMechanismFlagsIncidentTwo pins the 440 case). Major: the check's main purpose, flagging a forgotten busy loop, fails silently in the band, and the intent's Grounds say it is shown wrong by exactly that. The remainder spec spc-2609232027132755 holds the intent planned on this band. Fixing it needs a ruling on the stray definition (a share relative to what the machine could give the process, or a second sample), which the lane cannot take.
The load check's stray rule is silent across a load band that itd-2609231434459890's Mechanism, Decision 1 and Grounds claim it covers. A process is a stray only when it is older than the stray limit and its lifetime share of a core is at least 0.9 (NearFullShare, internal/core/machineload/classify.go); the extreme trigger fires only when the one-minute load is strictly above four times the online cores. Busy loops that have run for days each hold their fair share, cores divided by their count, so on 16 cores at the default limits: 17 loops (0.94 of a core each) warn through the stray trigger; 18, 20, 40 or 64 loops, a load between 1.125 and 4 times the cores, each hold under 0.9 of a core and raise no trigger, so the check is silent (no warning, no run-log event); from 65 loops the warning is the extreme trigger's alone, as at the 2026-09-22/23 incident's load of about 440, where the stray count read 0. The share filter applies before the uid split, so the band silences the caller's own loops as well as another account's. The fixture that shows it is TestStrayRuleSilentBand in internal/core/machineload/classify_test.go (TestMechanismFlagsIncidentTwo pins the 440 case). Major: the check's main purpose, flagging a forgotten busy loop, fails silently in the band, and the intent's Grounds say it is shown wrong by exactly that. The remainder spec spc-2609232027132755 holds the intent planned on this band. Fixing it needs a ruling on the stray definition (a share relative to what the machine could give the process, or a second sample), which the lane cannot take.
Grounds
- pursued: we expect every busy loop that has run past the stray limit to warn at any load, whatever its account; shown wrong if a loop using all the CPU it can get on a loaded machine is not counted, or if abcd's own concurrent preflights warn.
Frontmatter
| id | iss-2609231947544298 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2609231947544298-the-load-check-s-stray-rule-lifetime-cpu.md
open on GitHub ↗ · commit history ↗
mentions4
- dcn-26092400000000032026-09-24 — Release v0.10.0 is cut by autonomous run A, and the run's agenda line is: approve the publish step. Under ruling A2 of the product thinker's run A interview (2026-09-23 07:52Z, "approve the publish step": the product thinker authorises the run to approve the release environment itself once every gate is green), the run approves the `release` environment's deployment of v0.10.0 only after the merge queue, the verify job and every other gate on the tagged commit report green, and stops with a handover instead if any does not. The cut: v0.10.0, impact breaking, 43 records since v0.9.0 (nine shipped intents, thirty-four resolved or declined issues, four of them breaking), content commit 64ea8f62, the composer's payload accepted on the first ingest and recomposed once for two docs-currency findings. Both semantic gates ran at tier full: docs-currency-reviewer (Fable 5.1) with three findings, two fixed and one deferred because the load check's intent stays planned pending the product thinker's ruling on the stray definition (iss-2609231947544298); the brief-surface cross-check (40 pinned checkers, Opus 5.5, four at a time under the run's ceiling) with 154 findings, all deferred to their records: four user-facing ones captured as iss-2609240519413467, iss-2609240519418856, iss-2609240519471816 and iss-2609240519427388, one inside an appendix chapter captured as iss-2609240519422232, which records itd-147's ac-6 as not met, and the design-record drift to the systematic brief pass iss-2609091956001547.
- dcn-26092500000000122026-09-25 — The load check's stray rule is "busy for its share" (ruling H1, the product thinker via the interview session, 07:57Z, on iss-2609231947544298). A long-running process outside abcd's lanes is a stray when it uses nearly all the CPU it could get on the machine as loaded: its lifetime CPU share is measured against its fair share, the online cores divided by the runnable demand, not against a fixed 0.9 of one core, so forty busy loops each at a fortieth of the machine all count. The share test applies to the caller's own processes and to other accounts' alike, and other accounts' strays stay counted only. It is not a second sample and not a summed-cores trigger. The build reads the runnable demand as the snapshot's one-minute load average and caps the fair share at one core, so on a machine loaded no higher than its cores the rule is the near-full core it was (`machineload.FairShare`, spc-2609232027132755). This closes the band between 1.125 and 4 times the cores in which the check said nothing (pinned by `TestStrayRuleSilentBand`, succeeded by `TestStrayRuleCoversTheOversubscribedBand`), and lets the load check's remainder spec close and itd-2609231434459890 ship. The check still warns and never refuses (the 2026-09-23 entry above on that intent).
- itd-2609231434459890abcd's own tests warn before running on an overloaded machine
- spc-2609232027132755stray-rule-silent-band