5 ms·
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
by nbm 7y ago
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...
- menzoic 7y agoFuzz testing could help
- nbm 7y agoYep, 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.
- wbl 7y agoSee https://swtch.com/~rsc/regexp/ https://swtch.com/~rsc/regexp/ to understand why that isn't necessarily true.
- jswny 7y agoSounds like a job for property based testing!
- js2 7y agoCloudflare 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/cloudflare/lua-re2 https://github.com/google/re2 https://github.com/google/re2 https://github.com/google/re2/wiki/WhyRE2 https://github.com/google/re2/wiki/WhyRE2