#3014·karate

byte[] variables shared by reference through callonce / callSingle caches; unchecked Object[] casts crash on primitive arrays

Author: ptrthomasCreated Aug 15, 2026Updated Sep 4, 2026
Labelsbugfixed

Filed for tracking on behalf of @emudojo, who reported this by submitting the fix directly as PR #3013.

Problem

StepUtils.deepCopy — the isolation copy behind the callonce and callSingle result caches and callee variable deltas — deep-copied Maps and Lists but returned every array as-is. A byte[] (or any other array) inside a cached result was therefore shared by reference across scenarios and threads: mutating its contents in one scenario silently corrupted the cached value seen by every later scenario. The driver input() / waitForAny() JS bindings also cast any array to Object[] unchecked, throwing ClassCastException for primitive arrays such as byte[].

Fixed by

  • PR #3013 (merged as 61c24f43f): arrays cloned in deepCopy (primitive arrays via arraycopy, object arrays recursively with component type preserved); driver bindings guard the cast.
  • Follow-ups that fixed more instances of the same pattern found while reviewing:
    • 9227cf80f — cache isolation tests strengthened to mutate-then-verify.
    • 835b80646 — json-smart lacks writers for byte[]/char[] (same unchecked Object[] cast inside the library), which crashed print, match failure messages, JSON request bodies and reports whenever either was nested in a payload; the copy keyword's JSON round-trip mangled byte[], XML and top-level strings (now uses deepCopy); XML Node variables cloned since they are mutable via set by xpath; cycle detection now walks Object[].
    • 80cd01931 — external-review fixes: copied XML Elements detached into a fresh owner document, Set values copied, typed-array copy degrades to Object[] instead of ArrayStoreException, driver bindings iterate primitive arrays reflectively.

Known accepted limitations (documented in the commit messages): opaque POJOs remain by-reference in caches, and deepCopy has no cycle tracking (self-referential containers — same as Maps/Lists always behaved).

Will be closed when 2.1.3 is released to Maven Central.