Summary

Fixes BLOCK_INVALID (11): parent transaction X of tx Y has no block IDs that stalled both bsva-ovh-teranode-eu-3 (mainnet, height 302,681) and bsva-ovh-teranode-ttn-eu-4 (testnet, height 1,512,911) within ~8 minutes of each other on 2026-05-12 after upgrade to v0.15.0-beta-10.

Root cause

PR #711 (commit 95dbe32) added a quickValidation fast path: legacy netsync pre-assigns a block ID, bakes it into UTXO records during createUtxos, and skips the async setTxMinedStatus step by calling AddBlock(WithID, WithMinedSet(true)).

The fast path relies on createUtxos putting the block ID into every tx's BlockIDs at creation time. But when utxoStore.Create returned ErrTxExists for a tx that pre-existed (propagation arrival, prior crashed attempt, or the pre-fast-path subtreeValidation route), the previous code logged at Debug and returned nil:

if errors.Is(err, errors.ErrTxExists) {
    sm.logger.Debugf("failed to create utxo for tx %s: %s", txHash.String(), err)
} else {
    return err
}

The new block's ID was never merged into the existing tx's BlockIDs. Subsequent blocks failed validOrderAndBlessed in model/Block.go:1070-1072 (getParentTxMetaBlockIDs) and cascaded — every descendant block marked invalid, and the setTxMined recovery path with unsetMined=true then cleared BlockIDs on txs in those invalid blocks, deepening the corruption.

Pre-v0.15 the async setTxMinedStatus → SetMinedMulti path performed this merge implicitly after block accept. The fast path short-circuited that.

Fix

Mirror the pattern from services/blockvalidation/quick_validate.go:1106-1161 createAndSpendUTXOsForBatch:

1. During the parallel Create pass, collect tx hashes that returned ErrTxExists.
2. After the errgroup waits, issue one SetMinedMulti to merge the new blockID into all pre-existing records.

Reproduction timeline (eu-3, from Coralogix archive)

• 14:56:19Z legacy on pre-upgrade version starts processing block 302680 via the slow path (extendTransactions → subtreeValidation); subtreeValidation creates txs in the utxo store with empty BlockIDs.
• 14:56:24Z legacy errors: SUBTREE_ERROR (29): failed to check subtree → rpc Canceled (user-initiated upgrade restart).
• 14:56:45Z v0.15.0-beta-10 starts.
• 14:56:55Z legacy fast path createUtxos runs for block 302680. Tx 54ea96a0… already exists in store with empty BlockIDs → ErrTxExists → silently dropped.
• 14:56:56Z blockvalidation AddBlock stores 302680 with mined_set=true; setMinedChan worker logs "block already has mined_set true, skipping setTxMined".
• 14:56:58Z blockvalidation processes 302681; child tx 543094cd… has parent 54ea96a0… (which lives in 302680's subtree); getParentTxMetaBlockIDs finds it in store with empty BlockIDs → BLOCK_INVALID. Cascade follows.

Test plan

• go test -race ./services/legacy/netsync/... — 50 passed, including new TestSyncManager_createUtxos_MergesBlockIDsForExistingTxs which pre-creates a tx in a sqlitememory utxo store with empty BlockIDs, runs createUtxos, and asserts the new blockID was merged in.
• go vet ./services/legacy/netsync/... ./model/...
• golangci-lint run ./services/legacy/netsync/...
• staticcheck ./services/legacy/netsync/...
• Verify recovery on eu-3 / ttn-eu-4: deploy patched binary, then reconsiderblock on the invalid chain tip. Validation will re-execute, this time merging block IDs into the orphaned txs.

Notes

• Both affected hosts were resetting per user direction; the fix prevents recurrence.
• Other callers of utxoStore.Create with WithMinedBlockInfo should be audited for the same ErrTxExists silent-drop pattern; the equivalent path in services/blockvalidation/quick_validate.go already handles it correctly via a Phase 1.5 batch update.