Fix shared regex state across repeated matcher use (#749)

[chiliec]

Fixes #749.

Problem

A regex bound to a variable and reused across multiple $match/$replace/$split calls produces different results on repeated use, breaking JSONata's immutability guarantee. It worked in 1.8.7 / 2.0.1 and regressed by 2.0.6.

(
  $input := "a,b,c";
  $pattern := /[,-]/;
  {
    "2x": [$replace($input, $pattern, "|"), $replace($input, $pattern, "|")],
    "3x": [$replace($input, $pattern, "|"), $replace($input, $pattern, "|"), $replace($input, $pattern, "|")]
  }
)

Expected every element to be "a|b|c". On master it returns corrupted values such as "a|b|,b,|,|b,c".

Root cause

evaluateRegex builds one RegExp and closes over it:

var re = new environment.base.RegexEngine(expr.value);
var closure = function(str, fromIndex) {
    re.lastIndex = fromIndex || 0;
    ...

A regex literal bound to a variable is evaluated once, so the returned closure — and that single stateful re with its mutable lastIndex — is shared by every subsequent matcher call. $replace walks matches via the next() chain, which depends on re.lastIndex persisting; when another call reuses the same closure it resets/advances the same lastIndex, so independent calls interfere and corrupt each other's results.

Fix

Create a fresh RegExp for each top-level match walk (when the closure is entered without an existing instance), and thread that walk's own instance through the next() chain so multi-match iteration within a single walk is unchanged. Independent calls no longer share mutable regex state.

Test

Adds test/test-suite/groups/regex/case039.json, the repeated-use scenario from the issue (asserts every $replace yields "a|b|c").

Verification (local, Node 20.18.1)

• RED→GREEN: with the fix reverted, case039 fails (1799 passing / 1 failing); with the fix it passes (1800 passing / 0 failing).
• npm test — full suite green, and the strict gate holds: Statements/Branches/Functions/Lines all 100% (nyc check-coverage --branches 100 exits 0). The new branch is covered by case039.
• ESLint clean.

Signed-off-by: Vladimir Babin vovababin@gmail.com

[andrew-coleman]

Thanks for raising this, I agree it is a bug.

I don't quite agree on the root cause though. This same code works in the v1.x branch but has regressed in the V2.x (master) branch. This suggests the problem is caused by the lazy evaluation of the async/await mechanism in v2 vs generator pattern used in v1.

A simpler fix (tested) is to store the re.lastIndex in a variable just before the assignment of the result.next function. Then within that function definition, refer to that variable rather than re.lastIndex.

I.e.:

  var lastIndex = re.lastIndex;
  result.next = function() {
      if(lastIndex >= str.length) {
          return undefined;
      } else {
          var next = closure(str, lastIndex);

          ....

          return next;
      }
  };

Although your proposed fix works, it would cause a significant performance regression, especially if the regex guardrail hook was being used to perform static (ReDoS) analysis of the regex prior to compilation.

Happy for you to use the above code in your PR, or if you prefer I'll put this fix in a separate PR.

Many thanks :)