fix: four silent-wrong-result bugs in render, build, and network create

[barbatos2011]

Four correctness fixes across the render, build, and deploy paths. They were found while trying to stand up a two-node private network built from a specific java-tron commit — every one of them had the same shape: the command succeeded and produced a wrong result. No error, no warning, and in three of the four cases a green config validate.

Rebased on fbb3658. make test -race, make lint, and make e2e (real Docker) all pass.

---

1. config_overrides rendered Go syntax, not HOCON — fix(render)

hoconValue fell back to fmt outside the scalar cases, and Go syntax is only accidentally JSON:

[]any{map[…]}    %v  ->  [map[address:T… voteCount:5000]]   no HOCON parser accepts this
"ctrl\x01char"   %q  ->  a Go \x-escape, which is not a JSON/HOCON escape

The first made every list-valued override unusable. Most visibly it made genesis.block.witnesses unexpressible, so the two-SR DPoS private network tron-docker documents could not be built from an intent file at all.

Both now render through a JSON encoder — HOCON is a JSON superset, so the encoder is the correct renderer. SetEscapeHTML(false) keeps URLs readable. Numbers deliberately stay on fmt; a test pins that so the next refactor has to change it on purpose.

2. build.revision labelled the artifact without building it — fix(build)

The git worktree checkout ran only when build.patches was non-empty. With an explicit branch/tag/sha and no patches, gradle ran in the caller's working tree — and then the resolved sha went into the cache key, the manifest and status.build_revision.

So two trond build --revision <ref> runs against different refs could return byte-identical artifacts under two different labels. Anyone using this to compare a base commit against a head commit would be comparing an artifact with itself, and the tooling would confirm the labels.

schema.go already documented the field as selecting "which git revision to build"; the code did the resolve half and skipped the build-that-commit half. revision: HEAD still builds the working tree with dirty edits — that is the dev inner loop, and the dirty state is already in the cache key.

3. network create bypassed apply.Apply — fix(network)

The multi-node loop hand-rolled render + Deploy + state and had drifted from the core in three ways:

• it never imported internal/build, so a node with build: rendered an empty image: and deployed nothing usable
• it hardcoded jdk=17 instead of probing the target
• it hardcoded the docker runtime instead of honouring target.runtime

Every node now goes through Apply, projected to a single-node intent with its own name and hash so idempotency stays per node.

Two things had to be fixed in Apply first, both found by doing the refactor rather than by reading it:

• Apply never wrote P2PPort. network add builds the joining node's peer list from the P2PPort of every node in state and skips zero entries. Routing create through Apply as-is would have left every node invisible as a peer, so a late joiner would come up with an empty peer list and never connect — with nothing in either command's output to say why.
• Monitoring would have deployed once per node. RenderHOCON keys its metrics auto-enable off Intent.Monitoring, so the field cannot simply be cleared. Options.SkipMonitoring suppresses the deploy and leaves the field alone. Without it the last node's stack wins and scrapes exactly one node — a monitoring setup that looks healthy and observes a fraction of the network.

Two consequences of create becoming an Apply caller, both wanted: it inherits RenderHOCONWithSecrets (#202) instead of keeping a second copy of that call in sync by hand, and it now passes guard.Requested() so the state-based half of the --require-private gate (#203) applies here too.

4. jvm.extra_opts — feat(intent)

JVMConfig was closed over heap and GC. java-tron ships operational flags in gradle/java-tron.vmoptions, read by its distribution launcher bin/FullNode; trond runs the JAR directly, so that file never applies and there was no way to supply them.

-Dio.netty.allocator.type=pooled is the case that forced this — java-tron sets it to opt out of netty 4.2's adaptive allocator, which has open direct-memory regressions upstream. Deployed through trond, a node ran on the allocator java-tron had explicitly avoided.

Appended last, because the JVM takes the final occurrence of -XX:± and -D — appending earlier would make the field look wired while trond's own flag quietly won. A test pins the ordering.

Validation is an allowlist by construction: only -D<key>=<value> and -XX:…, so -javaagent / -agentlib / -cp / @argfile are excluded by shape rather than by blocklist, and a JVM flag added upstream tomorrow cannot slip in. Whitespace is refused, and that rule is load-bearing rather than tidiness: JVMArgs joins with spaces, so "-Dfoo=bar -XX:+Evil" in one list item reads as an innocuous property in the intent and arrives as two JVM arguments.

---

Testing

• make test -race — 25 packages, 0 failures
• make lint — no findings
• make e2e — full suite against a real Docker daemon, including TestE2E_Network_PrivateLifecycle (2 containers, create → status → destroy)
• New tests use the property as the oracle where possible: rendered HOCON values are parsed back rather than string-compared; the build tests assert the contents of the tree gradle saw, not the label on the artifact

One note for reviewers: the HOCON tests deliberately do not parse the whole rendered document. gurkankaymak/hocon cannot parse any of the shipped java-tron templates — private fails at 112:22, mainnet at 37:5, nile at 103:5 — even before an override is appended. Typesafe Config, which java-tron actually uses, accepts them. The tests therefore parse the rendered value.

Not covered

• network create --monitor is unit-tested but not exercised with real containers
• target.type: ssh on the multi-node path is untested