Problem

CreateUTXOSet writes a 16-byte footer (txCount + utxoCount, both little-endian uint64) after the final UTXOWrapper in every UTXO-set file. But the OUTER loop that reads a previous block's UTXO set during consolidation (services/utxopersister/UTXOSet.go) only broke out on a clean io.EOF. With the footer present, the next txid read came up 16 bytes short and io.ReadFull returned io.ErrUnexpectedEOF, which the loop treated as fatal:

STORAGE_ERROR (69): error reading previous utxo-set (...) at iteration 1
  -> STORAGE_ERROR (69): failed to read txid, expected 32 bytes got 16
  -> UNKNOWN (0): unexpected EOF

That error propagates out of the UTXOPersister service start and, via the errgroup, tears down the entire core sidecar on any non-genesis consolidation.

Why it surfaced now

This OUTER loop was dead code for non-genesis previous sets — verifyLastSet crashed earlier on the fileformat-magic double-read. #971 fixed that crash, which made this path reachable for the first time and exposed the latent footer bug. Found by the split-per-service chaos harness: a node receiving peer blocks while its blockassembly is down triggers the consolidation read, and the core sidecar dies with RPC connection-refused.

Fix

Break the loop when the wrapper read short-reads the footer, in addition to the clean io.EOF case.

The short read is matched by substring ("unexpected EOF"), and the comment is explicit that this is not a structural match: teranode's errors.New flattens a non-*Error cause to its message string (errors/errors.go:334-336), discarding the io.ErrUnexpectedEOF sentinel, so errors.Is(err, io.ErrUnexpectedEOF) would itself reduce to the same strings.Contains. This is intentionally narrower than cmd/utxovalidator (which also matches "failed to read txid"), so a real non-EOF read error stays loud rather than being swallowed. The comment also warns not to fold the io.EOF clause into errors.Is — "EOF" is a substring of "unexpected EOF" and would swallow the footer error too.

Known limitation (pre-existing, not worsened here): a genuinely truncated tail is indistinguishable from the footer and is silently accepted — same as cmd/utxovalidator today. A structural fix — FromReader returning a typed sentinel, plus validating records-read == txCount against the footer across the consolidation loop, the seeder, and utxovalidator — is a follow-up. Realistic impact of the limitation is a seeded node stalling on a missing UTXO (recoverable by re-seed), not double-spend acceptance.

Test

Added TestCreateUTXOSet_PreviousSetWithFooterTerminatesCleanly, which stages a realistic previous set (68-byte header + one wrapper + 16-byte footer). It reproduces the exact production error without the fix and passes with it.

The pre-existing previous-set test passed only because it staged zero wrappers and no footer, hitting a clean io.EOF and never exercising the footer path.

Verification

• go test ./services/utxopersister/ (full package) and -race — pass
• go vet, gofmt, gci — clean
• Test-first: confirmed the test fails without the fix (exact got 16 -> unexpected EOF) and passes with it
• End-to-end: rebuilt the image with this fix and ran the split-per-service chaos scenario (scenario_04, currently skipped) with the skip removed locally — full run passed (node stalls while blockassembly is down, catches up after restart, all three nodes converge). Un-skipping that scenario is a follow-up PR.