JDK_JAVA_OPTIONS in the environment breaks Mill's daemon RPC, reported as 'Worker wire broken'

mph commented

2026-09-01 15:32:30 +00:00

Owner

Found triaging IW-436 (LESSONS.md entry 5). Blocked the whole of IW-436 Phase 2.

Every ./mill and ./iw invocation failed with:

java.lang.IllegalStateException: Worker wire broken, worker likely crashed. Connection DaemonRpcClient

out/mill-daemon/server.log shows the real cause on the server side:

connection handler ... error: upickle.core.TraceVisitor$TraceException: $
Caused by: ujson.ParseException: expected json value got "G" at index 0

Root cause

The daemon reads non-JSON on the RPC wire. The environment has JDK_JAVA_OPTIONS=-XX:MaxRAMPercentage=10 set, which makes every JVM Mill spawns print NOTE: Picked up JDK_JAVA_OPTIONS: ... on start-up. That line lands on the pipe the daemon parses as JSON.

Confirmed by bisection, both directions:

env -u JDK_JAVA_OPTIONS ./mill show core.jar — succeeds.
./mill --no-daemon show core.jar — succeeds, and prints the NOTE: line in its own output where it is harmless.
./mill show core.jar with the variable set — fails every time, on a fresh out/mill-daemon as well as an existing one.

Why it matters

This is an environment fault, not an iw-cli defect, but it is invisible in the launcher's own error text — the launcher reports a crashed worker and says nothing about the wire content. A developer who hits this has no path from the message to the cause without reading out/mill-daemon/server.log.

Workaround used for the whole of IW-436 Phase 2: prefix every build command with env -u JDK_JAVA_OPTIONS.

Wanted

./mill and ./iw survive a set JDK_JAVA_OPTIONS — the wrapper can unset it for the daemon launch.
The failure text points at out/mill-daemon/server.log.

#443 records the same family — a long-lived build daemon failing as something other than what it reports — and names "the first was Mill's worker: Worker wire broken, worker likely crashed" without finding the cause. This issue is that cause.

Found triaging IW-436 (LESSONS.md entry 5). Blocked the whole of IW-436 Phase 2. Every `./mill` and `./iw` invocation failed with: ``` java.lang.IllegalStateException: Worker wire broken, worker likely crashed. Connection DaemonRpcClient ``` `out/mill-daemon/server.log` shows the real cause on the server side: ``` connection handler ... error: upickle.core.TraceVisitor$TraceException: $ Caused by: ujson.ParseException: expected json value got "G" at index 0 ``` ## Root cause The daemon reads non-JSON on the RPC wire. The environment has `JDK_JAVA_OPTIONS=-XX:MaxRAMPercentage=10` set, which makes **every JVM Mill spawns** print `NOTE: Picked up JDK_JAVA_OPTIONS: ...` on start-up. That line lands on the pipe the daemon parses as JSON. Confirmed by bisection, both directions: - `env -u JDK_JAVA_OPTIONS ./mill show core.jar` — succeeds. - `./mill --no-daemon show core.jar` — succeeds, and prints the `NOTE:` line in its own output where it is harmless. - `./mill show core.jar` with the variable set — fails every time, on a fresh `out/mill-daemon` as well as an existing one. ## Why it matters This is an environment fault, not an iw-cli defect, but it is invisible in the launcher's own error text — the launcher reports a crashed worker and says nothing about the wire content. A developer who hits this has no path from the message to the cause without reading `out/mill-daemon/server.log`. Workaround used for the whole of IW-436 Phase 2: prefix every build command with `env -u JDK_JAVA_OPTIONS`. ## Wanted - `./mill` and `./iw` survive a set `JDK_JAVA_OPTIONS` — the wrapper can unset it for the daemon launch. - The failure text points at `out/mill-daemon/server.log`. ## Related #443 records the same family — a long-lived build daemon failing as something other than what it reports — and names "the first was Mill's worker: `Worker wire broken, worker likely crashed`" without finding the cause. **This issue is that cause.**

mph referenced this issue

2026-09-01 15:33:16 +00:00

CI compile job must not fail on a Bloop server timeout #443

mph referenced this issue from a commit

2026-09-01 15:36:36 +00:00

workflow: Triage lessons for IW-436

mph referenced this issue

2026-09-01 15:36:57 +00:00

IW-436: review-state CLI — fix five flag-parsing and update-semantics defects #499

mph referenced this issue

2026-09-04 21:29:27 +00:00

ci(checks): a change that touches no code does not run the code checks #527

mph referenced this issue

2026-09-11 18:18:31 +00:00

viteBuild takes WEBAWESOME_NPM_TOKEN from the Mill daemon, so a daemon started without it breaks dashboard builds in a fresh worktree #544

claude commented

2026-10-15 22:31:06 +00:00

Member

Intake: agent-ready
Workflow: diagnostic
Reason: all gates passed
Analysis: project-management/issues/IW-494/analysis.md on branch IW-494

Intake: agent-ready Workflow: diagnostic Reason: all gates passed Analysis: project-management/issues/IW-494/analysis.md on branch IW-494

claude added the

agent-ready

label

2026-10-15 22:31:06 +00:00

claude commented

2026-10-15 23:06:44 +00:00

Member

Implement: needs-human
Reason: batch-implement exit 1 — the kanon plugin did not compile against the core of this branch, so no phase ran

main changed the tracker port to return Either[TrackerError, …] (#778, #780). The installed kanon plugin still expects Either[String, …] at lib/batch/ForgeCatchUp.scala:143. This failure is not specific to this issue: every iw-cli issue stops at the same point until the plugin agrees with the core again. No batch-implement.log was written. The output of the command:

[warn]  Using directives detected in multiple files:
- /home/mph/.local/share/iw/plugins/kanon/lib/deps.scala:1:1-7:41
It is recommended to keep them centralized in the /home/mph/Devel/iw/iw-cli-IW-494/core/project.scala file.

[error] /home/mph/.local/share/iw/plugins/kanon/lib/batch/ForgeCatchUp.scala:143:7
[error] Found:    Either[iw.core.model.TrackerError, Option[batch.ForgeState]]
[error] Required: Either[String, Option[batch.ForgeState]]
Compilation failed

Implement: needs-human Reason: batch-implement exit 1 — the kanon plugin did not compile against the core of this branch, so no phase ran `main` changed the tracker port to return `Either[TrackerError, …]` (#778, #780). The installed kanon plugin still expects `Either[String, …]` at `lib/batch/ForgeCatchUp.scala:143`. This failure is not specific to this issue: every iw-cli issue stops at the same point until the plugin agrees with the core again. No `batch-implement.log` was written. The output of the command: ``` [warn] Using directives detected in multiple files: - /home/mph/.local/share/iw/plugins/kanon/lib/deps.scala:1:1-7:41 It is recommended to keep them centralized in the /home/mph/Devel/iw/iw-cli-IW-494/core/project.scala file. [error] /home/mph/.local/share/iw/plugins/kanon/lib/batch/ForgeCatchUp.scala:143:7 [error] Found: Either[iw.core.model.TrackerError, Option[batch.ForgeState]] [error] Required: Either[String, Option[batch.ForgeState]] Compilation failed ```

claude added

needs-human

and removed

agent-ready

labels

2026-10-15 23:06:44 +00:00

claude commented

2026-10-16 17:10:34 +00:00

Member

Release: the implement loop failed this issue for a reason outside it. The kanon plugin did not compile against iw-cli main, because the tracker port now returns TrackerError (iw-cli #778). The plugin fix is dev-docs #484, and iw-cli 0.22.1 carries the core change. The issue goes back to the implement loop.

claude added

agent-ready

and removed

needs-human

labels

2026-10-16 17:10:34 +00:00

Rows
Columns

JDK_JAVA_OPTIONS in the environment breaks Mill's daemon RPC, reported as 'Worker wire broken' #494

Root cause

Why it matters

Wanted

Related