Query rules must reject requests on regex resource-limit failures instead of continuing #6510

Maintainer decision

A query-rule regex runtime/resource-limit failure must reject the affected client request with an explicit error. It must not silently skip policy and continue toward another rule or the default route. This records the maintainer's RT17=B decision during the behavior review.

This changes the fallback previously specified in closed #6466 ("rule not applied"). Keep the resource/stack protections introduced for #6466 and #6423; this follow-up changes failure propagation, not the safety limits.

Current behavior

Source checked at 9516441f7bd6fdb93f255f1881db19ca9ee56778.

In rule_matches_regex():

• PCRE1 recursion/match-limit failures make regex_is_valid=false.
• PCRE2 heap/depth/match-limit failures and other runtime match errors also make regex_is_valid=false.
• The helper logs a rate-limited warning and returns false, excluding the whole rule whether negated or not.
• Its boolean result does not propagate the evaluation failure as a client error, so later/default policy may execute the request.

Example: a rule determines whether a query belongs in hostgroup 20. Evaluating its pattern exhausts the resource budget. ProxySQL skips the rule and may execute the request through the remaining/default route in hostgroup 10. The client receives execution under a routing decision made without completing the applicable regex evaluation.

The shared Query Processor affects both MySQL and PostgreSQL. PCRE1 is engine 1 on all tiers; PCRE2 is engine 3 on v3.1/v4.0.

Required behavior

• Preserve a distinction between a legitimate no-match and a runtime evaluation failure. Negation applies to a completed match result, not an error.
• Propagate a real runtime/resource-limit failure through the Query Processor result to the protocol handler and return a clear client error. Do not continue to another/default route or serve a cached success after the failure.
• Apply the contract consistently to match_digest and match_pattern, for both PCRE engines and both protocols.
• Preserve worker stack, CPU and heap limits and existing memory cleanup. A limit hit must not crash the process.
• Include sufficient diagnostics to identify the rule, regex operation/engine and error reason without flooding logs.

Also check the related substitution path: PCRE1/PCRE2 rewrite failures currently leave SQL unchanged and continue, while earlier rule outputs can already have been assigned. Handle real runtime/resource failures consistently rather than fixing only one helper and retaining another silent continuation path. An ordinary no-match/no-replacement remains distinct from an execution error.

Validation

Cover PCRE1 recursion/match limits and PCRE2 heap/depth/match limits; positive and negated patterns; match_digest and match_pattern; MySQL and PostgreSQL. Demonstrate that no later/default backend execution or cached success occurs after a failure, normal matches/non-matches retain their semantics, and subsequent valid requests remain usable with correct protocol/transaction state. Cover substitution failure without execution of unchanged or partially rewritten SQL.

This report is based on source tracing. Runtime reproductions and tests have not been executed for this issue.

Related: #6466, #6423, #6411. This does not request reopening the separately defined compatibility policy for invalid patterns at compile/load time.