---
title: "Why the FAILED Regex Went Through Three Forms"
canonical: https://dxdev.com/blog/red-test-left-red-on-purpose/
datePublished: 2026-10-03
---
Four of the six nightly test failures got fixed, and the other two stayed red on purpose. Those two were a live-data alarm, so a failing test was the correct output, and we left them failing.

What changed is the nightly report. It now marks each failed test as known-red or new, and the regex that parses its `FAILED` lines went through three forms on the way.

## The report

When `$rc` is nonzero, the nightly script reads the log and collects the `FAILED` lines from the current run, everything after the `=== $stamp begin ===` line. The original match was:

```
^FAILED (\S+)
```

The failure notice listed the first 25 ids and pointed at the log for the rest.

We added a known-red file, one pytest node id per line. Its header ends with the rule that keeps it honest:

```
# Delete a line as soon as its test is green. Empty = nothing is excused.
```

The report marks a failed test `[known-red]` if its id is in that file and `[NEW]` if it is not. The heading counts both, in the form `Failed tests (N: X new, Y known-red)`. That is how the two deliberately red tests stay visible without paging anyone as if they were fresh breakage.

The marker checks each captured id against the lines of the known-red file with `-contains`. That commit still captured with `\S+`.

## The first rewrite, which was wrong

The next commit changed the match so node ids containing spaces would be kept whole. It matched up to the ` - ` that precedes the failure message:

```
^FAILED (.+?)( - |$)
```

We added `test_failed_line_pattern_keeps_node_ids_that_contain_spaces`. The test asserts the regex text appears literally in the `.ps1`, then runs a Python copy of the same pattern against two lines:

- `FAILED tests/t.py::test_x[a b] - AssertionError: x` gives `tests/t.py::test_x[a b]`.
- `FAILED tests/t.py::test_y` gives `tests/t.py::test_y`.

Both passed, and the fix looked finished. But the only bracketed sample in the test, `test_x[a b]`, had a space and no hyphen. Splitting on ` - ` is exactly what breaks a parametrized id that contains ` - ` inside its brackets, and the test never put one there.

## Alongside the regex

Two other fixes went into the same commits:

- The health count of enriched threads was double counting stragglers that had a sidecar twin, so `enriched` could exceed `indexed`. The dedupe first compared the raw `uid`, and a later commit made it compare `str(uid)` so a numeric uid matches its sidecar twin.
- The failure notice now leads with the failing test ids.

## The third form

The last commit's message names the case the second form missed: a bracketed param id containing ` - `. This time the pattern stopped looking for the separator and described the shape of the id instead:

```
^FAILED ([^\s\[]+(?:\[[^\]]*\])?)
```

That is a run of characters with no whitespace and no ``, then optionally one bracketed group. The test changed in two places, since the [literal-string assertion and the Python copy both switched to the new pattern. We also added the case that had been missing, with a ` - ` inside the brackets:

```python
assert pat.match("FAILED tests/t.py::test_z[a - b] - boom").group(1) == "tests/t.py::test_z[a - b]"
```

`FAILED tests/t.py::test_z[a - b] - boom` now has to give `tests/t.py::test_z[a - b]`.