[nbm]

Since the work involved in doing a regular expression match can depend largely on the input for non-trivial expressions, one fun case (probably not the one here, though) is that a user of your system could start using a pathological case input that no amount of standard testing (synthetic or replayed traffic, staging environments, production canaries) would have caught.

Didn't take anything down, but did cause an inordinate amount of effort tracking down what was suddenly blocking the event loop without any operational changes to the system...

[wbl]

See https://swtch.com/~rsc/regexp/ to understand why that isn't necessarily true.

[js2]

Cloudflare uses re2 which doesn't suffer this problem, but apparently they don't use it here?

https://github.com/cloudflare/lua-re2

https://github.com/google/re2

https://github.com/google/re2/wiki/WhyRE2

[jswny]

Sounds like a job for property based testing!

[menzoic]

Fuzz testing could help

[nbm]

Yep, it could help in some cases.

It's nowhere near as standardly applied as the other approaches to release verification, though.

And in complex cases (say, a large multi-tenant service with complex configuration), it can be very hard to find the combination of inputs necessary to catch this issue. If you have hundreds of customer configurations, and only one of them has this particular feature enabled (or uses this sort of expression), fuzzing is less likely to be effective.