lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

chore(buglog): correct bug-1830, mem-limit usage population is not categorically broken

Browse source 
User's own independent retest against a real deployed cluster produced
a fully populated, correctly human-formatted mem-based limit usage
line (limits2: accounted=18022400.000000 (17.19 MB)
capacity=4635344384.000000 (4.32 GB)) -- directly contradicting the
original entry's "never populates" framing, which was based on a
single short-lived agent-run live test.

Downgraded from a confirmed defect to an unreproduced, timing/
session-shape-dependent observation. The original single-run finding
was real and remains unexplained, but a categorical "mem-based limits
don't populate usage via replay" claim is now known to be false.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RLSNJhNoULvVcUhXEFafQC
This commit is contained in:
Rongsong Shen 2026-09-20 09:20:07 +00:00
parent 38d9fe3583
commit 07b5c989b5
No known key found for this signature in database
GPG key ID: 5BCDAAE0123E9FE2
1 changed files with 7 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

12
.wolf/buglog.json
View file

@ -24610,10 +24610,10 @@
{
"id": "bug-1830",
"timestamp": "2026-09-20T09:00:00Z",
"error_message": "NOT A CRASH -- live-verification finding while manually demonstrating scheduler-sim-diagnostics Requirement 6 (human-readable info limit formatting) against a real deployed cluster. A mem-based limit (limits2, ug1_global_mem, night_mem_pct -- all from the real src/configs/limits.yaml) never populates a live usage instance via `info limit all` against a real captured replay, even when the matching job is genuinely dispatched and its rusage[mem=...] reservation is confirmed intact (via `info job <id>`). A slots-based limit (limit1) in the SAME replay, against a matching dispatched job, DOES correctly populate a usage instance (accounted=0.00, capacity=3.00) -- so this is resource-type-specific to mem, not a general replay/limit-matching failure.",
"error_message": "CORRECTED 2026-09-20 (user's own independent retest) -- original framing was too strong. A mem-based limit (limits2, from the real src/configs/limits.yaml) DID correctly populate a live usage instance in a user-run retest: `info limit limits2` against a real replay showed `usage limit=limits2/u=rshen/q=xce/p= host=pc13v: accounted=18022400.000000 (17.19 MB) capacity=4635344384.000000 (4.32 GB)` -- fully populated and correctly human-formatted on both accounted and capacity. This directly contradicts this entry's original claim that mem-based limits 'never' populate a usage instance via replay. ORIGINAL FINDING (retained for context, now understood to be narrower than stated): an earlier live-verification session (agent-run, single short-lived deploy+capture cycle) saw every mem-based limit show 'no active usage instance yet' while a slots-based limit in the same replay populated correctly. Given the user's retest succeeded, the real condition is likely session-shape/timing-dependent (e.g. elapsed replay rounds, WORKERS_PUSH arrival timing relative to job dispatch, or how long the recording ran) rather than a categorical mem-vs-slots failure.",
"file": "src/scheduler/src/plugins/limit.c",
"root_cause": "Suspected, not confirmed: match_job_global_limit_()/match_job_host_limit_() (plugins/limit.c) key_find() the limit's constrained resource by name against core->resmgr at match time. For `slots`, this resource is always already present in core->resmgr from session start. For `mem`, the resource may only become known to core->resmgr via a WORKERS_PUSH replay event reporting the worker's live mem value -- if that push event is decoded/applied AFTER the job's own dispatch decision is replayed (or never lands in the resmgr in a way key_find() can see before the match attempt), the mem-based limit's match silently misses, leaving no xce_vres_t/usage instance ever created for it. test_sim_e2e_limit_visibility.c's own acceptance test (scheduler-sim-live-allocation task 5.2) only proves this works when the mem resource is hand-baked directly into the snapshot's resmgr BEFORE any replay event is processed -- it does not cover the ordinary real-deployment shape (resource known only via a live WORKERS_PUSH event that arrives as part of the replay stream itself, not pre-seeded in the snapshot). This needs direct tracing of match timing vs. WORKERS_PUSH application order in sim_loop.c's real round sequence to confirm.",
"fix": "NOT FIXED -- discovered during live manual verification, out of scheduler-sim-diagnostics Requirement 6's boundary (that feature is display-formatting only, and is proven correct independent of this finding: the configured-value line and any usage line that DOES populate both render human-readable correctly, confirmed live). Also out of scheduler-sim-live-allocation's already-closed boundary (bug-1826 there was specifically about limit MATCHING never being invoked at all during replay -- now fixed; this is a narrower, resource-type-specific timing/ordering gap in when a match against core->resmgr can succeed for a resource whose registration itself arrives via replay rather than being pre-seeded). Needs its own dedicated investigation: trace WORKERS_PUSH application order against match_job_global_limit_()/match_job_host_limit_()'s call timing in a real multi-round replay for a mem-based (not slots-based) limit.",
"fix": "STATUS DOWNGRADED to investigation-needed, not a confirmed defect. The original agent-run live test's single short capture window may not be representative -- the user's own longer/different retest shows mem-based limit usage population DOES work under real replay conditions. If this is ever seen to fail again, the reproduction needs to capture the SPECIFIC session shape that fails (replay round count, elapsed time between record-start and the job's dispatch, WORKERS_PUSH cadence) since a bare 'mem-based limits don't populate' framing has now been shown to be incorrect as a categorical claim. Not fixed because there is no longer a confirmed, reproducible defect to fix -- downgrading rather than closing, since the ORIGINAL single agent-run observation was real and unexplained, just not reproduced by the user's own retest.",
"tags": [
"scheduler",
"sim-mode",
@ -24622,17 +24622,19 @@
"limit-matching",
"mem-resource",
"live-verification-finding",
"not-fixed",
"related-to-bug-1825",
"related-to-bug-1826",
"discovered-during-scheduler-sim-diagnostics-requirement-6-live-test"
"discovered-during-scheduler-sim-diagnostics-requirement-6-live-test",
"corrected",
"not-reproduced-by-user",
"needs-better-repro"
],
"related_bugs": [
"bug-1825",
"bug-1826"
],
"occurrences": 1,
"last_seen": "2026-09-20T09:00:00Z"
"last_seen": "2026-09-20T09:30:00Z"
}
]
}