Skip to content

Fix checker crashes silently passing validation as valid#11

Open
RPRKLR wants to merge 1 commit into
FlexBE:mainfrom
RPRKLR:fix/checker-crash-validation
Open

Fix checker crashes silently passing validation as valid#11
RPRKLR wants to merge 1 commit into
FlexBE:mainfrom
RPRKLR:fix/checker-crash-validation

Conversation

@RPRKLR

@RPRKLR RPRKLR commented Jul 1, 2026

Copy link
Copy Markdown

The two catch blocks in checkBehaviorReport() assumed every caught
error was a custom {path, error} object (as thrown by
Behavior.createStructureInfo / checkStatemachine). A real JS exception
(e.g. a TypeError from a bug in the checker) has no .error property, so:

- checking.js:189 pushed `error.error` == undefined onto
  report.fatal_errors. checkBehavior() then returns fatal_errors[0]
  == undefined, which callers read as "no error" -> a behavior that
  actually failed the check could be saved or started as if valid.

- checking.js:199 called `error.path.replace(...)` unconditionally.
  On a real exception .path is undefined, so this threw a second
  TypeError inside the catch handler, masking the original error.

Both handlers now resolve a non-empty message
(error.error -> error.message -> String(error)), so a checker crash
always produces a real fatal error instead of undefined. The
container-navigation logic is guarded by if (error.path != undefined)
so it only runs for the custom {path, error} objects that carry a path.

  The two catch blocks in checkBehaviorReport() assumed every caught
  error was a custom {path, error} object (as thrown by
  Behavior.createStructureInfo / checkStatemachine). A real JS exception
  (e.g. a TypeError from a bug in the checker) has no .error property, so:

    - checking.js:189 pushed `error.error` == undefined onto
      report.fatal_errors. checkBehavior() then returns fatal_errors[0]
      == undefined, which callers read as "no error" -> a behavior that
      actually failed the check could be saved or started as if valid.

    - checking.js:199 called `error.path.replace(...)` unconditionally.
      On a real exception .path is undefined, so this threw a second
      TypeError inside the catch handler, masking the original error.

  Both handlers now resolve a non-empty message
  (error.error -> error.message -> String(error)), so a checker crash
  always produces a real fatal error instead of undefined. The
  container-navigation logic is guarded by `if (error.path != undefined)`
  so it only runs for the custom {path, error} objects that carry a path.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants