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:
parent
077b1213d3
commit
b5712c053d
6 changed files with 117 additions and 9 deletions
|
|
@ -48,6 +48,7 @@
|
|||
snprintf(auxil->errmsg, sizeof(auxil->errmsg),
|
||||
"unknown resource '%s'", name);
|
||||
}
|
||||
auxil->unknown_resource = 1;
|
||||
auxil->has_error = 1;
|
||||
return NULL;
|
||||
}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue