Severity: HIGH (data race, corrupted $current/$parent semantics)

Location: query/sql/executor/FetchFromClusterExecutionStep.java:120 (context.setVariable("current", result) inside each workers rs.next()), FetchFromTypeExecutionStep.java:331, BasicCommandContext (variablesis a plainHashMap, lazily created in init()`).

In the parallel path up to bucketCount pool workers call rs.next() concurrently on the same CommandContext, each doing variables.put("current", ...) into an unsynchronized HashMap - racing each other and the consumer. Under load: lost entries, corrupted table during resize, and the classic HashMap infinite-loop/corruption outcomes. It also silently breaks \$current/\$parent for downstream expressions. (Profiling counters are also updated racily - benign.)

Fix: give each scan task its own child context (context.copy() per worker) and set current only on the consumer; a ConcurrentHashMap for variables is a weaker fallback that still leaves the semantic breakage.

Filed from an internal engine deep-audit (2026-07). Traced to source; verify against current main before fixing and add a regression test.