Summary
check_ruleset()'s rname extraction (repo-config/configure.sh, around line 254) reads the ruleset payload's .name with jqr '.name // empty' "$file" and no failure guard: rname="$(jqr '.name // empty' "$file")". If the payload file is not valid JSON, jqr (jq -r | sed) returns non-zero, and since this assignment is not part of any if/while condition, set -Eeuo pipefail aborts the entire check run rather than reporting a graceful per-ruleset failure the way the function's later reads do (compare the guarded if ! want_types="$(jqr ... "$file")"; then fail "..."; return; fi a few lines down).
Because rname is the first payload read in check_ruleset(), it is also the actual first point of failure for a malformed ruleset payload: guarding a later extraction (.enforcement, done in #1246) does not by itself make the function fail gracefully on malformed JSON, since the abort already happens here first.
Suggested fix
Guard the rname extraction the same way want_types already is:
if ! rname="$(jqr '.name // empty' "$file")"; then
fail "ruleset payload $file did not parse"
return
fiContext
Found while fixing #1246, verifying a review finding about a different, adjacent unguarded read (.enforcement) in the same function. Filed separately since rname's extraction predates #1246's diff and guarding it is a different, non-CRLF concern (general parse-failure handling, not the Windows CRLF exposure #1246 fixes).
Confirmed empirically: a malformed payload file passed to check_ruleset() aborts the whole script at this line (jq: parse error..., non-zero exit) rather than reporting fail "ruleset payload ... did not parse", even with #1246's .enforcement guard in place, because this read runs first.
Summary
check_ruleset()'srnameextraction (repo-config/configure.sh, around line 254) reads the ruleset payload's.namewithjqr '.name // empty' "$file"and no failure guard:rname="$(jqr '.name // empty' "$file")". If the payload file is not valid JSON,jqr(jq -r | sed) returns non-zero, and since this assignment is not part of anyif/whilecondition,set -Eeuo pipefailaborts the entirecheckrun rather than reporting a graceful per-ruleset failure the way the function's later reads do (compare the guardedif ! want_types="$(jqr ... "$file")"; then fail "..."; return; fia few lines down).Because
rnameis the first payload read incheck_ruleset(), it is also the actual first point of failure for a malformed ruleset payload: guarding a later extraction (.enforcement, done in #1246) does not by itself make the function fail gracefully on malformed JSON, since the abort already happens here first.Suggested fix
Guard the
rnameextraction the same waywant_typesalready is:Context
Found while fixing #1246, verifying a review finding about a different, adjacent unguarded read (
.enforcement) in the same function. Filed separately sincername's extraction predates #1246's diff and guarding it is a different, non-CRLF concern (general parse-failure handling, not the Windows CRLF exposure #1246 fixes).Confirmed empirically: a malformed payload file passed to
check_ruleset()aborts the whole script at this line (jq: parse error..., non-zero exit) rather than reportingfail "ruleset payload ... did not parse", even with #1246's.enforcementguard in place, because this read runs first.