---
id: "bug-1887"
status: "fixed"
status_updated: "2026-09-29"
status_note: ""
component: "lib"
severity: "wrong-result"
timestamp: "2026-09-29T09:48:49Z"
last_seen: "2026-09-29T09:48:49Z"
occurrences: 1
files: ["src/lib/xce_resreq.peg", "src/lib/resreq.c"]
tags: ["lib", "resreq", "parser"]
related: ["bug-1884"]
fix_commits: ["b5712c05"]
---

# bug-1887: resreq parser ignores a primary's select/rusage parse error and accepts the job without that clause

## Description
**Observed:** (code reading) the `primary_resreq` action in
src/lib/xce_resreq.peg calls
`parse_resreq_primary(primary, $0, auxil->resmgr, &(auxil->errmsg))`
and ignores its return value; nothing sets `has_error`, so
`parse_resreq()` returns success. A primary whose select or rusage clause
fails to parse is kept without that clause (select NULL / rusages empty),
i.e. the job is scheduled as if it had no such constraint. While fixing
bug-1884 a LeakSanitizer report showed such an error message being
produced during a normal replay fixture (its job's resreq parsed "OK").

**Expected:** a primary sub-parse error makes `parse_resreq()` fail with that message (the job is rejected/pended with a parse error), not silently dropped.
**Impact:** wrong result: a job with a malformed select (e.g. a typo) may dispatch onto hosts its select would have excluded.
**Found by:** review (while fixing bug-1884, 2026-09-29)

## Environment
- OS: no /etc/os-release; Docker container; NixOS kernel; kernel Linux 6.18.33 x86_64
- libc: glibc 2.42-47 (interpreter /nix/store/wb6rhpznjfczwlwx23zmdrrw74bayxw4-glibc-2.42-47/lib/ld-linux-x86-64.so.2)
- Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
- Build: asan (src/xce.build.discrete)
- Code: scheduler-framework @ 90b99d91-dirty
- Deployment: n/a (found by code reading while fixing bug-1884; not observed on a deployment)

## Reproduction
1. Read the `primary_resreq` action in src/lib/xce_resreq.peg and `parse_resreq_primary()` in src/lib/resreq.c.
2. Unit check: `parse_resreq(&r, "select[type==] rusage[mem=1]", resmgr, &err)` -- expect rc < 0; observe the return value.
- Frequency: deterministic for any malformed select/rusage inside a primary
- Evidence: not kept; LeakSanitizer stack from the bug-1884 fixture (strdup in parse_select error path under core_build_job)

## Root cause
The `primary_resreq` action in src/lib/xce_resreq.peg ignored `parse_resreq_primary()`'s result and nothing set `has_error`, so `parse_resreq()` succeeded for a primary whose select/rusage clause failed to parse and the job kept no such clause. Confirmed with a probe (2026-09-29): `select[type==]`, `select[mem>]`, `select[type==any && ]` all returned rc=1 with select NULL; `select[gpu>1]` with no gpu resource likewise.

## Fix
A malformed clause now fails the whole resreq and `parse_resreq()` returns the clause's own message (b5712c05). A select naming an unregistered resource is still dropped rather than rejected: parse_select() reports it as -ENOENT (new select_context_t.unknown_resource) and the action lets it pass, because jobs rely on it -- the scheduler's own "type == any" default among them when no "type" resource is registered (making it fatal failed 36 scheduler suites). Whether an unknown resource in a select should reject the job is left as a separate decision. Making syntax errors fatal exposed bug-1888.

## Verification
- Test: test_resreq_primary_select_error_fails_parse in src/lib/testsuite/test_resreq.c (xkvmgr resmgr with type/mem; syntax errors incl. inside a compound fail with a message; unknown resource still parses with select NULL; valid select kept): RED before (all accepted), GREEN after
- Suites: ASAN debug build (src/xce.build.discrete), `meson test --no-suite xceadmin`: 117/117 OK, 0 sanitizer reports; xcelib_test 695 tests 0 failures (2026-09-29)
- Live: 3-round sequential HA soak on rebuilt ASAN binaries (/home/claude/tmp/xce-bug1885-soak, 2026-09-29): PASS, 15 jobs, zero job loss, all 3 nodes led; SIMVERIFY 4 files 0 mismatches; each recording replays with detect_leaks=1 at exit 0, 0 mismatches; no sanitizer report in the scheduler or controller stderr

## References
- Related: bug-1884