Fresh dockerized node never produces blocks: getShard maxShardSize=0 -> NotInShardError every consensus round (contradicts INSTALL.md "isolated single-validator chain by default")

[cX3po]

Second crash from running the stabilisation branch per your invite — and this one blocks local L2PS testing, since the chain can't advance.

What happens

After getting the stack up (via the #913 lockfile workaround — drop --frozen-lockfile/the bun.lock COPY), all containers are healthy and the node RPC responds, but the node never produces a block — block stays 0, ready:false — and the consensus routine loops this every ~2s:

[ERROR] [CORE] We are not in the shard
[ERROR] [CORE] NotInShardError: We are not in the shard
[ERROR] [CORE] [consensusRoutine] Exiting consensus routine

Observed root cause (from the node's own logs)

[CORE] Common validator seed: 4e9ad6b833a07ec...
[CORE] [SNAPSHOT] validators: seeded 4
[CORE] NETWORK_PARAMETERS ... "shardSize":4 ...
[CORE] [getShard] maxShardSize: 0          <-- shardSize is 4, but maxShardSize resolves to 0

Genesis seeds 4 baked validators (none of which is this fresh node's identity, 0xe734dece...), and getShard then computes maxShardSize: 0, so the shard is empty and this node is "not in the shard" on every round — consensus exits and no block is ever produced.

Why it matters / the contradiction

INSTALL.md states: "A fresh node will run as an isolated single-validator chain by default." In practice a fresh dockerized node from the documented quickstart cannot produce a single block — so a new operator can't do local dev, and (relevant to the current push) can't exercise L2PS locally because the chain is frozen at genesis.

Repro

git clone -b stabilisation https://github.com/kynesyslabs/node.git && cd node
# apply the #913 lockfile workaround so the build succeeds
cp .env.example .env
docker compose up -d --build
curl -s http://localhost:53550/info   # block:0, ready:false; logs loop NotInShardError

Questions / likely fix

Should a fresh solo node either (a) seed its own identity into the validator set so it's in the shard (true "isolated single-validator chain"), or (b) is maxShardSize:0 the actual defect (shardSize=4 but maxShardSize resolves to 0 with 4 seeded validators)? Either way, the docs and behavior disagree, and a documented "make yourself a validator for solo dev" step would unblock local testing. (May relate to the getShard shard-selection / validator-set handling.)

Environment

v0.9.8 "Oxlong Michael", stabilisation, Docker 28.4 / Compose v2.39, 2026-06-01. Happy to share full logs or test a fix.

— PATH-OS Labs (pathos-dacs-ref), running the stabilisation node per your invite.

[cX3po]

We have the stabilisation stack running locally and are blocked here for L2PS testing (chain frozen at genesis), so happy to help close the loop fast:

1. We'll re-test and confirm the instant you push a fix.
2. If useful, we can contribute a small regression test asserting a fresh node produces block 1 within N seconds (fails today, passes once a fresh node can self-validate).

This is in the validator/shard area you mentioned you're actively reworking, so we're deliberately not PR-ing the consensus code — offering the test + fast re-test instead. Just say the word.

[cX3po]

Update — we reproduced a working fix locally, which also pins the root cause.

Root cause (confirmed): getShard computes maxShardSize = min(shardSize, validatedPeers.length), where validatedPeers = online peers ∩ active validators. The default data/genesis.json seeds the baked validators, but a fresh node's own auto-generated identity is never added to the validator set — so on a solo node validatedPeers = ∅, maxShardSize = 0, and the node is permanently "not in the shard" → no blocks.

Fix reproduced: adding the node's own identity (its 0x… address) to the genesis validator set makes a fresh node enter the shard ([getShard] maxShardSize: 1) and produce blocks — verified locally block 0 → 3, and the L2PS subsystem then runs in the consensus loop ([consensusRoutine] L2PS took 7ms) instead of booting skipped.

So the documented "isolated single-validator chain by default" needs either (a) a documented/automated "seed self as validator" step for solo/dev mode, or (b) the default genesis to include the operating node's identity. Happy to PR a small docs/setup note for the solo-dev path if useful — and this now unblocks us to exercise L2PS locally for you.

— PATH-OS Labs, running the stabilisation node per your invite.