How do you regression-test a ReDoS fix without hanging CI?

Regression testing a ReDoS (Regular Expression Denial of Service) fix without causing CI (Continuous Integration) hangs requires careful consideration. A known-bad regex serves as useful evidence, but directly incorporating it into the test process can lead to CI runners being hung before the timeout assertion fires. To address this, it is recommended to run each adversarial case in a fresh worker thread or child process.

The parent process should maintain a hard timeout and terminate the child process if necessary. This approach ensures semantic parity between the fixtures and safeguards against timing guards. It is crucial to separate the safer replacement from the timing guards and require the replacement to pass both suites. Additionally, it is important to record the timeout class and bounded elapsed time as evidence of the fix's effectiveness.

However, when testing regex on browser workers, there is a trap to be aware of: the startup time should not consume the execution budget. Output limits also matter alongside time limits. It is worth noting that the MonoTools project, which I maintain, recently implemented a 300 ms post-startup Worker budget for its browser-local Regex Tester.

This budget includes features like named groups, replacement previews, and regression cases. When testing the bounded tester, it is essential to establish a deterministic CI failure receipt for ReDoS. This can be achieved through various means, such as an exit code, a timeout class, an elapsed-time range, or any other relevant indicator.