Skip to content

Record a dirty exit under --check-exitcode as a test failure - #258

Open
gdesmott wants to merge 1 commit into
masterfrom
push-tvwmlkukywsr
Open

gdesmott wants to merge 1 commit into
masterfrom
push-tvwmlkukywsr

Conversation

@gdesmott

@gdesmott gdesmott commented Oct 6, 2026 •

Copy link
Copy Markdown
Collaborator

takeEnvDown already records 'redis process failure' against the test whose server did not exit cleanly, which is enough to fail the run and name the test in the summary. Under --check-exitcode it then also raises, and nothing above takeEnvDown catches that exception: it escapes the env scope guard of run_single_test.

The raise predates parallel execution (#147): both it and the recorded failure came with --check-exitcode itself. With parallelism, the exception ends the worker process, so:

  • the failure is never shipped to the coordinator, and the summary does not name the test, or is not printed at all;
  • the tests still queued on that worker are not run, so a single dirty exit hides an unknown number of other results;
  • self.currEnv is left set, since the raise skips its reset.

That is the same failure mode #257 removed for an exception raised from tearDown. The run stays failed without the raise, through the recorded failure. A dirty exit under --use-valgrind, which also sets require_clean_exit, already takes that path: it records the failure without raising. --exit-on-failure remains the option for stopping at the first failure.


Note

Low Risk
Small teardown-path change; failure behavior is preserved via recorded test failures instead of an uncaught exception.

Overview
takeEnvDown no longer raises when Redis exits dirty under --check-exitcode. A dirty shutdown still prints the message and records redis process failure on the test via addFailure, so the run fails and the summary names the test—same as with --use-valgrind.

Removing the raise Exception('Process exited dirty') stops that exception from escaping EnvScopeGuard during parallel runs, where it previously killed the worker, dropped queued tests, skipped shipping failures to the coordinator, and left self.currEnv uncleared. --exit-on-failure remains the way to stop at the first failure.

Reviewed by Cursor Bugbot for commit a5c5d8d. Bugbot is set up for automated code reviews on this repo. Configure here.

…of raising

takeEnvDown already records 'redis process failure' against the test
whose server did not exit cleanly, which is enough to fail the run and
name the test in the summary. Under --check-exitcode it then also raises,
and nothing above takeEnvDown catches that exception: it escapes the env
scope guard of run_single_test.

The raise predates parallel execution (#147): both it and the recorded
failure came with --check-exitcode itself. With parallelism, the
exception ends the worker process, so:

- the failure is never shipped to the coordinator, and the summary does
  not name the test, or is not printed at all;
- the tests still queued on that worker are not run, so a single dirty
  exit hides an unknown number of other results;
- self.currEnv is left set, since the raise skips its reset.

That is the same failure mode #257 removed for an exception raised from
tearDown. The run stays failed without the raise, through the recorded
failure. A dirty exit under --use-valgrind, which also sets
require_clean_exit, already takes that path: it records the failure
without raising. --exit-on-failure remains the option for stopping at
the first failure.
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.

1 participant