---
id: "bug-1830"
status: "cannot-reproduce"
status_updated: "2026-09-24"
status_note: "downgraded 07b5c989; user's own retest showed mem limit usage correctly"
component: "scheduler"
severity: "unknown"
timestamp: "2026-09-20T09:00:00Z"
last_seen: "2026-09-20T09:30:00Z"
occurrences: 1
files: ["src/scheduler/src/plugins/limit.c"]
tags: ["scheduler", "sim-mode", "repl", "limit-plugin", "limit-matching", "mem-resource", "live-verification-finding", "related-to-bug-1825", "related-to-bug-1826", "discovered-during-scheduler-sim-diagnostics-requirement-6-live-test", "corrected", "not-reproduced-by-user", "needs-better-repro"]
related: ["bug-1825", "bug-1826"]
repro_attempts: "user retest 2026-09-20, not reproduced"
legacy: true
gitea_issue: 53
gitea_synced_status: "cannot-reproduce"
---

# bug-1830: CORRECTED 2026-09-20 (user's own independent retest) -- original framing was too strong

## Description
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.

## Environment
_Not recorded (migrated from buglog.json)._

## Reproduction
- Attempts: user retest 2026-09-20, not reproduced

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

## Verification
_Not recorded (migrated from buglog.json)._

## References
- Related: bug-1825, bug-1826
- Gitea: #53