Second regression fix for the plasma-consensus 0.15.0→1.1.0 bump (issue #5309, PR #5310/companion #89 merged 2026-09-28T01:30Z). The first regression (--nat flag, PR #5316) is already fixed and merged; after redeploying rpc-de-27 a new failure appeared:
plasma-mainnet-node-1 | INFO plasma_cli: Validating observer node configuration
plasma-mainnet-node-1 | Error: Network misconfiguration: trusted_only=true but no trusted_peers configured; node would be isolated
Root cause: PR #89's config-schema migration converted [validators.N]→[network.bls_peer_ids]/[chain.static_committee.N] and [[network.bootstrap_nodes]]→indexed [network.bootstrap_nodes.N], but silently dropped the pre-existing [[network.trusted_peers]] array (3 entries pointing at the plasmalabs.tech bootstrap observers) while leaving trusted_only = true in place. Not part of the documented schema changes in #5309/PR #89.
Fix: restored the 3 [[network.trusted_peers]] entries verbatim (same peer_id/address pairs as pre-migration commit 672f626b), immediately after the [network.bootstrap_nodes.N] blocks in plasma/mainnet/non-validator.toml. trusted_only is unchanged (true) — same trust posture as before the bump, no new peers added. Nothing else in the file was touched.
Impact of not merging:plasma-mainnet-node-1 (observer) on rpc-de-27 stays isolated/crash-looping; the paired reth has been stalled at latest_block=33349025 since 2026-09-28T00:48Z (no consensus updates, ~8h now).
Rollout plan: after merge, redeploy rpc-de-27 only (single host), then verify: plasma-mainnet-node-1 container Up with no crashloop, logs show it connecting to trusted peers, reth resumes advancing past latest_block=33349025. Fleet propagation follows as a separate, non-gating step once verified.
Commit: 43c800e43043b64554610fe42e6ca3fc4e95fc6e on branch vupd/5309-plasma-consensus-trusted-peers-fix.
Second regression fix for the plasma-consensus 0.15.0→1.1.0 bump (issue #5309, PR #5310/companion #89 merged 2026-09-28T01:30Z). The first regression (`--nat` flag, PR #5316) is already fixed and merged; after redeploying `rpc-de-27` a new failure appeared:
```
plasma-mainnet-node-1 | INFO plasma_cli: Validating observer node configuration
plasma-mainnet-node-1 | Error: Network misconfiguration: trusted_only=true but no trusted_peers configured; node would be isolated
```
**Root cause:** PR #89's config-schema migration converted `[validators.N]`→`[network.bls_peer_ids]`/`[chain.static_committee.N]` and `[[network.bootstrap_nodes]]`→indexed `[network.bootstrap_nodes.N]`, but silently dropped the pre-existing `[[network.trusted_peers]]` array (3 entries pointing at the plasmalabs.tech bootstrap observers) while leaving `trusted_only = true` in place. Not part of the documented schema changes in #5309/PR #89.
**Fix:** restored the 3 `[[network.trusted_peers]]` entries verbatim (same peer_id/address pairs as pre-migration commit `672f626b`), immediately after the `[network.bootstrap_nodes.N]` blocks in `plasma/mainnet/non-validator.toml`. `trusted_only` is unchanged (`true`) — same trust posture as before the bump, no new peers added. Nothing else in the file was touched.
**Impact of not merging:** `plasma-mainnet-node-1` (observer) on `rpc-de-27` stays isolated/crash-looping; the paired reth has been stalled at `latest_block=33349025` since 2026-09-28T00:48Z (no consensus updates, ~8h now).
**Rollout plan:** after merge, redeploy `rpc-de-27` only (single host), then verify: `plasma-mainnet-node-1` container Up with no crashloop, logs show it connecting to trusted peers, reth resumes advancing past `latest_block=33349025`. Fleet propagation follows as a separate, non-gating step once verified.
Commit: `43c800e43043b64554610fe42e6ca3fc4e95fc6e` on branch `vupd/5309-plasma-consensus-trusted-peers-fix`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Restore the [[network.trusted_peers]] array-of-tables that was silently
dropped during the 0.15.0->1.1.0 config-schema migration (PR #89).
The trusted_peers entries ensure the observer can connect to the Plasma
mainnet bootstrap nodes even with trusted_only=true.
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Second regression fix for the plasma-consensus 0.15.0→1.1.0 bump (issue #5309, PR #5310/companion #89 merged 2026-09-28T01:30Z). The first regression (
--natflag, PR #5316) is already fixed and merged; after redeployingrpc-de-27a new failure appeared:Root cause: PR #89's config-schema migration converted
[validators.N]→[network.bls_peer_ids]/[chain.static_committee.N]and[[network.bootstrap_nodes]]→indexed[network.bootstrap_nodes.N], but silently dropped the pre-existing[[network.trusted_peers]]array (3 entries pointing at the plasmalabs.tech bootstrap observers) while leavingtrusted_only = truein place. Not part of the documented schema changes in #5309/PR #89.Fix: restored the 3
[[network.trusted_peers]]entries verbatim (same peer_id/address pairs as pre-migration commit672f626b), immediately after the[network.bootstrap_nodes.N]blocks inplasma/mainnet/non-validator.toml.trusted_onlyis unchanged (true) — same trust posture as before the bump, no new peers added. Nothing else in the file was touched.Impact of not merging:
plasma-mainnet-node-1(observer) onrpc-de-27stays isolated/crash-looping; the paired reth has been stalled atlatest_block=33349025since 2026-09-28T00:48Z (no consensus updates, ~8h now).Rollout plan: after merge, redeploy
rpc-de-27only (single host), then verify:plasma-mainnet-node-1container Up with no crashloop, logs show it connecting to trusted peers, reth resumes advancing pastlatest_block=33349025. Fleet propagation follows as a separate, non-gating step once verified.Commit:
43c800e43043b64554610fe42e6ca3fc4e95fc6eon branchvupd/5309-plasma-consensus-trusted-peers-fix.🤖 Generated with Claude Code
merge-bot (del-018): classified B (hand-maintained rpc file(s), single scope). Auto-merge after a 72h objection window - comment 'hold' to block.