Four test cases under describe('js-executor'):
- sandbox isolates args from host realm (JVN#16937365 — regression guard)
- sandbox passes string args through unchanged
- non-sandbox path does not isolate from host realm (documented contract)
- non-sandbox path passes string args through unchanged
Tests use Node's built-in node:test + node:assert (zero new devDependencies;
ts-node was already there). Two npm scripts:
test — spec output for local dev
test:ci — spec to stdout + Node's built-in junit reporter to
target/surefire-reports/TEST-js-executor.xml
Wired 'yarn test:ci' into the Maven 'test' phase via frontend-maven-plugin,
so 'mvn test -pl=msa/js-executor' produces JUnit XML that TeamCity's
Maven runner auto-discovers under the 'js-executor' suite name.
TEST_FAST.md picks up the same step.
tsconfig excludes test/ from the production pkg bundle.
The args array passed into the sandbox carried the host realm prototype
chain, so a script could reach the host Function constructor via
args.constructor.constructor and execute arbitrary code in the host
process (read files, run shell commands, dump env vars).
Construct args inside the sandbox context using vm.runInContext('[]'),
then populate with string primitives. The resulting array's prototype
chain belongs to the sandbox realm, so constructor traversal cannot
escape. Strings are primitives and safe to cross the realm boundary.
Affects use_sandbox=true path only. The use_sandbox=false path
(invokeFunction) is intentionally left as-is and explicitly marked as
dangerous-by-design — it compiles and runs user-supplied scripts in
the host realm via vm.compileFunction (parsingContext only isolates
parsing, not execution). It remains as a documented performance
trade-off for trusted, non-public clusters; a startup WARN is logged
when script.use_sandbox=false, and an operator-facing yaml comment
sits next to the setting in config/default.yml.
Reported by Hiroki Imai, LAC Co., Ltd.
--no-bytecode is only required for the Windows target; running pkg as a
single multi-target invocation applied it to Linux too, dropping V8
bytecode from the Linux exe. Split into two pkg invocations so Linux
keeps bytecode and only the Windows build relaxes it.
Under `mvn -T<n>` with the three yarn-using modules (ui-ngx,
msa/web-ui, msa/js-executor), concurrent yarn 1.x processes contend
on the shared `~/.cache/yarn`. The `--mutex network` flag was applied
only to `yarn install`, so `yarn run pkg` could overlap with another
module's install. Intermittent failures observed on CI:
`/bin/sh: 1: tsc: not found` during `yarn run pkg`, caused by
incomplete typescript extraction into per-module node_modules.
Fix at two layers:
1. Maven reactor chain (primary): add reactor-only pom <dependency>
entries (type=pom, scope=provided, wildcard exclusions) to form
ui-ngx -> msa/web-ui -> msa/js-executor
so the MultiThreadedBuilder schedules them strictly serial,
regardless of -T thread count. msa/web-ui already had a real
dependency on ui-ngx; only one new fake link was needed.
2. Yarn-level mutex (defense in depth): add `--mutex network` to
`yarn run pkg` (msa/web-ui, msa/js-executor) and
`yarn run build:prod` (ui-ngx), so single-module builds outside the
reactor chain (`mvn -pl msa/<module>`) still serialize against any
other yarn process on the agent.
Comment in msa/pom.xml updated: the previous "Modules order is
important..." note was misleading - module order in the reactor does
not enforce serialization under -T; the dependency edges do.
Remove <pkg.skip.bootjar>false</pkg.skip.bootjar> from all child
module <properties> blocks. The root POM already defaults it to false,
and child declarations block the skip-pkg profile override, so
-Dpkg.skip=true was never actually skipping spring-boot:repackage.
Also remove the unused surefire.version property (superseded by
maven-surefire-plugin.version).
The com.spotify:dockerfile-maven-plugin:1.4.13 is deprecated and broken
on modern macOS (Apple Silicon) due to its Java HTTP client being
incompatible with current Docker Desktop socket/API.
Replace the Java-based plugin with exec-maven-plugin calling the docker
CLI directly — the same approach already used by the multiarch push
profiles (push-docker-amd-arm-images).
All existing Maven property contracts preserved:
- dockerfile.skip (default true) controls docker build
- push-docker-image profile for single-arch push
- push-docker-amd-arm-images profiles unchanged (already use exec)
Introduces four independent flags to skip individual packaging artifacts:
-Dpkg.skip.bootjar=true skip spring-boot repackage (*-boot.jar)
-Dpkg.skip.deb=true skip Gradle buildDeb + Maven attach-artifact
-Dpkg.skip.rpm=true skip Gradle buildRpm
-Dpkg.skip.zip=true skip maven-assembly-plugin Windows ZIP
Adds -Dpkg.skip=true as a single convenience flag that sets all four
at once. msa/pom.xml mirrors the skip-pkg profile to override its own
<pkg.deb.phase>package</pkg.deb.phase> property (child POM properties
have higher priority than parent profile properties in Maven).
msa/* docker modules used ${basedir}/../.. (non-canonical) for main.dir.
maven-enforcer-plugin 3.5.0's osIndependentNameMatch() compares
file.toURI() vs file.getCanonicalFile().toURI() — these differ when the
path contains '..', causing RequireFilesExist to report false-negative.
Fix: replace ${basedir}/../.. with ${maven.multiModuleProjectDirectory}.
When building with -T6, multiple JS modules run yarn install concurrently.
The --mutex network flag serializes yarn processes, but if node_modules from
a previous build (or a different branch/version) is left on disk, yarn may
skip reinstalling packages — including devDependencies — treating the stale
state as up-to-date. This causes tools like tsc to be missing at build time.
Configure maven-clean-plugin to delete node_modules during mvn clean for
all JS modules (ui-ngx, msa/js-executor, msa/web-ui). Yarn restores from
its global cache (~/.cache/yarn), so the overhead is relinking only.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sergey Matvienko
Volodymyr Babak
Vladyslav_Prykhodko
dashevchenko
Viacheslav Klimov