Skip to content

fix(runner): recognise runtime errors from the exit code, not only English text - #1000

Merged
Chemaclass merged 1 commit into
mainfrom
fix/998-locale-independent-runtime-errors
Aug 8, 2026
Merged

fix(runner): recognise runtime errors from the exit code, not only English text#1000
Chemaclass merged 1 commit into
mainfrom
fix/998-locale-independent-runtime-errors

Conversation

@Chemaclass

Copy link
Copy Markdown
Member

🤔 Background

Related #998

detect_runtime_error matched English phrases — command not found and ~20 more. bash translates its diagnostics, so under any locale with the message catalogue installed none of them matched, and a genuine failure-to-run was reported as a plain assertion failure — losing the Error/Failed distinction that exists to tell those apart.

The repo runs Spanish, Brazilian and Japanese locale jobs, so this was a supported configuration, not a hypothetical.

💡 Changes

Exit codes carry the same fact without any text: the shell reserves 127 for "could not find it" and 126 for "found it, could not run it". Both are consulted only after the text scan draws a blank, so English behaviour is unchanged — including the more specific message the text produces, which is still preferred when available.

🎁 Wider than the locale case

A test that redirects the diagnostic away still exits 127. This is a real fixture in the suite:

function test_error() {
  set -e
  invalid_function_name arg1 arg2 &>/dev/null
}

Its Error message used to be empty — the text the scan needed had gone to /dev/null. It now reads command not found (exit code 127). The snapshot diff is worth reading: it replaces an empty message with the cause.

-
+command not found (exit code 127)

🔧 Two structural notes

  • extract_result_counts now runs before detect_runtime_error so the exit code is available to it — safe because it's documented and verified as a pure read that commits nothing.
  • The line scan moved into its own helper: it used to return from the caller on a text miss, which would have skipped the new fallback entirely. Caught because the new tests stayed red after the first implementation.

✅ Verification

4 new tests, RED first, covering: translated text + 127, translated text + 126, an ordinary failure exit code that must not classify, and English text still winning over the code.

make sa · make lint · bash build.sh bin -v✅ Build verified ✅ · 1717 sequential / 1676 parallel-simple-strict.

…glish text

Closes #998.

detect_runtime_error matched English phrases -- "command not found" and about
twenty more. bash translates its diagnostics, so under any locale with the
message catalogue installed none of them matched and a genuine failure-to-run
was reported as a plain assertion failure, losing the Error/Failed distinction
that exists to tell those apart. The repo runs Spanish, Brazilian and Japanese
locale jobs, so this was a supported configuration, not a hypothetical.

Exit codes carry the same fact without any text: the shell reserves 127 for
"could not find it" and 126 for "found it, could not run it". Both are consulted
only after the text scan draws a blank, so English behaviour is unchanged --
including the more specific message the text produces, which is still preferred
when available.

The gain is wider than the locale case. A test that redirects the diagnostic
away still exits 127:

    function test_error() {
      set -e
      invalid_function_name arg1 arg2 &>/dev/null
    }

That is a real fixture in this suite. Its Error message used to be empty,
because the text the scan needed had been sent to /dev/null; it now reads
"command not found (exit code 127)". Snapshot updated to match, and the diff is
worth reading -- it replaces an empty message with the cause.

Two structural notes. extract_result_counts now runs before detect_runtime_error
so the exit code is available to it; that is safe because it is documented and
verified as a pure read that commits nothing. And the line scan moved into its
own helper: it used to `return` from the caller on a text miss, which would have
skipped the new fallback entirely.

1717 sequential / 1676 parallel; baseline + 4, RED first.
@Chemaclass Chemaclass added the bug Something isn't working label Aug 8, 2026
@Chemaclass Chemaclass self-assigned this Aug 8, 2026
@Chemaclass Chemaclass added the bug Something isn't working label Aug 8, 2026
@Chemaclass
Chemaclass merged commit 63d3208 into main Aug 8, 2026
37 checks passed
@Chemaclass
Chemaclass deleted the fix/998-locale-independent-runtime-errors branch August 8, 2026 13:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant