fix(lib): a malformed select in a resreq fails the parse instead of being dropped (bug-1887)

The primary_resreq action ignored parse_resreq_primary()'s result, so a
primary whose select (or rusage) clause failed to parse was accepted
without that clause: select[type==] or select[mem>] matched every host.
A malformed clause now fails the whole resreq, and parse_resreq() returns
the clause's own message.

A select naming an unregistered resource is still dropped, not an
error: 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).

Test: test_resreq_primary_select_error_fails_parse RED before (all
accepted), GREEN after.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Rongsong Shen 2026-09-29 10:26:35 +00:00
parent 077b1213d3
commit b5712c053d
Signed by untrusted user: rshen
GPG key ID: 80533536B0EB651C
6 changed files with 117 additions and 9 deletions

View file

@ -191,6 +191,7 @@ struct select_context_t_ {
int err_pos;
int has_error;
char errmsg[256]; /* fixed-size — no alloc/free in grammar actions */
int unknown_resource; /* bug-1887: the error was an unknown resource name */
int depth; /* current nesting depth — guard vs SELECT_MAX_DEPTH */
xce_select_node_t* root; /* result root set by grammar top-level action */
};