A contributor working on #18 (PR #26) reported: "Full test suite: 73 passed, 1 pre-existing failure in test_catastrophic_backtracking_pattern_does_not_hang on Windows." This was unrelated to their change (a one-line exception-type fix in schema.py), so it's being tracked separately rather than blocking that PR.
test_catastrophic_backtracking_pattern_does_not_hang (in tests/test_severe_edge_cases.py) spawns a subprocess with a 30-second timeout to verify a regex ReDoS guard actually prevents a hang. Timing-based tests like this are the classic source of platform-specific flakiness — Windows process spawn overhead, different regex engine performance characteristics, or a tighter effective timeout margin could all plausibly cause this.
What's needed
- Reproduce on Windows (or CI matrix — currently only
ubuntu-latest is tested, see .github/workflows/ci.yml) to confirm this is real and not a one-off environment issue on the reporter's machine.
- If real: determine whether it's a genuine timing margin problem (the guard is working, but 30s isn't enough headroom on slower Windows CI runners) vs. an actual bug in the ReDoS guard not working on Windows.
- If it's a timing margin issue, consider whether CI should add a Windows job to
ci.yml's test matrix to catch this class of bug going forward, or whether that's overkill for a single test.
Not enough information yet to say more — this issue exists to track investigating it, not to prescribe the fix.
A contributor working on #18 (PR #26) reported: "Full test suite: 73 passed, 1 pre-existing failure in test_catastrophic_backtracking_pattern_does_not_hang on Windows." This was unrelated to their change (a one-line exception-type fix in
schema.py), so it's being tracked separately rather than blocking that PR.test_catastrophic_backtracking_pattern_does_not_hang(intests/test_severe_edge_cases.py) spawns a subprocess with a 30-second timeout to verify a regex ReDoS guard actually prevents a hang. Timing-based tests like this are the classic source of platform-specific flakiness — Windows process spawn overhead, different regex engine performance characteristics, or a tighter effective timeout margin could all plausibly cause this.What's needed
ubuntu-latestis tested, see.github/workflows/ci.yml) to confirm this is real and not a one-off environment issue on the reporter's machine.ci.yml's test matrix to catch this class of bug going forward, or whether that's overkill for a single test.Not enough information yet to say more — this issue exists to track investigating it, not to prescribe the fix.