Skip to content

fix(network): join newly added node to the running mesh#181

Open
warku123 wants to merge 2 commits into
tronprotocol:developfrom
warku123:fix/network-add-shared-network
Open

fix(network): join newly added node to the running mesh#181
warku123 wants to merge 2 commits into
tronprotocol:developfrom
warku123:fix/network-add-shared-network

Conversation

@warku123
Copy link
Copy Markdown

What does this PR do?

Fixes trond network add so the new node actually joins the running private network instead of sitting orphaned. Two related fixes:

  1. Attach the new container to the shared trond-<name> docker network (was only on its per-compose bridge).
  2. Auto-populate node.active from existing nodes in state so the new node knows whom to dial.

Adds a state.ManagedNode.P2PPort field so step 2 can read the listen port without the create-time intent.

Why are these changes required?

network create already does both steps via the sharedNet loop and autoWireActivePeers in cmd/network/create.go. network add was never updated to mirror them, so an added node has no DNS reachability to siblings and no peer list to dial — it stays at 0 peers and never syncs blocks, even though state and naming look correct.

This PR has been tested by:

  • Unit Tests — go build ./... clean.
  • Manual Testing — created a 2-node private network via trond network create, added a third fullnode via trond network add. Verified the new container attaches to trond-<name>, the rendered HOCON contains the populated node.active list, and the new node received blocks 1–38 over P2P from the witness within ~30s (RestartCount=0).
  • Backward compatibility — P2PPort uses omitempty; legacy state entries read as 0 and are skipped from the auto-wire (same convention as HTTPPort / GRPCPort).

Follow up

  • autoWireActivePeers runs only at create time; this PR fills the gap unilaterally for the new node (sufficient because P2P channels are bidirectional once established), but the design may warrant revisiting for denser networks.
  • Pre-existing bug, unrelated: trond diagnose reports peer_count=0 for clearly-peered nodes because its probe queries /wallet/listnodes, which only surfaces discovery-found peers. Tracking separately.

Extra details

warku123 added 2 commits May 22, 2026 15:29
network create wires every node's compose to the shared
trond-<name> network so siblings can resolve each other by
container name. network add skipped this step — the new node
landed only on its per-compose bridge and stayed at 0 peers,
and any service on trond-<name> (e.g. the monitoring stack)
could not reach it either.

Append trond-<name> to node.Networks before render, mirroring
the loop already used by network create.
Now that the new node attaches to the shared trond-<name> docker
network (previous commit), it can resolve sibling container names —
but it still has no active_peers entry, so it doesn't know which
peers to dial. java-tron with discovery off (private network
default) only connects to nodes listed in node.active, so without
this the new node sits silent on the network despite being
reachable.

Populate the new node's active_peers from existing entries in
state, mirroring autoWireActivePeers in network create. Because P2P
connections are bidirectional once established, we only update the
new node — existing nodes accept the incoming connection and
broadcast back without needing a config rewrite or restart.

state.ManagedNode gains a P2PPort field so add can read each
sibling's listen port from state instead of re-parsing intent files
(which add no longer has access to for nodes deployed earlier).
network create now persists it too. Legacy state entries that
predate the field get P2PPort=0 and are skipped from the active
list — the field comment documents the same fallback the existing
HTTPPort / GRPCPort fields use.
@warku123 warku123 changed the title Fix/network add shared network fix(network): join newly added node to the running mesh May 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant