Skip to content

fix(config): invalidate cached genesis on parse failure#126

Merged
hanzo-dev merged 1 commit into
mainfrom
fix/invalidate-stale-genesis-cache
Jun 1, 2026
Merged

fix(config): invalidate cached genesis on parse failure#126
hanzo-dev merged 1 commit into
mainfrom
fix/invalidate-stale-genesis-cache

Conversation

@hanzo-dev
Copy link
Copy Markdown
Member

Drops the stale cached genesis.bytes file when its parse fails (codec mismatch on binary upgrade). Prevents permanent CrashLoop after type-ID-bumping releases. Surfaced today on Liquidity testnet+mainnet bumping v1.9.x → v1.10.8: 'unknown type ID 29' on the stale v1.9.x codec cache.

…ashLooping

The cached `<dataDir>/genesis.bytes` file is written on first start to
hold hash stability across restarts. On a binary upgrade that adds
new codec types (multi-version v0+v1 dispatcher, etc.), the old
cached blob may carry type IDs the new binary doesn't recognise. The
existing code surfaced this as `resolve X-Chain asset ID from cached
genesis: unmarshal interface: unknown type ID N` and returned an
error — wedging the node in CrashLoop with no automatic recovery.

Drop the cache and rebuild from the `--genesis-file` instead. Hash
stability is forfeit for that single restart (intentional — the
alternative is a permanent outage on every binary bump that changes
codec types). Subsequent restarts re-establish stability against the
fresh cache.

Surfaced today on Liquidity testnet+mainnet bumping lqd v1.9.x →
v1.10.8: every pod hit "unknown type ID 29" on the stale v1.9.x
codec cache and CrashLoopBackOff'd.
@hanzo-dev hanzo-dev merged commit 6564bf2 into main Jun 1, 2026
8 of 16 checks passed
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