[satran004]

Problem

transaction_metadata, assets, transaction_scripts and mir use a random UUID primary key and are saved with JPA saveAll. When a block is processed a second time, its rows get new ids and are inserted again. This happens on restart: the app rolls back to the cursor block, and on the BlockFetch path it re-fetches from that block inclusive. Tables keyed by natural keys simply overwrite. These four gain one duplicate per row of the block. On a mainnet DB, transaction_metadata had 76 rows for 38 (tx_hash, label) at one restart slot and 176 for 88 at another.

Fix

1. The rollback point is deleted when it will be processed again (cherry-picked from the snapshot branch). The startup RollbackEvent now says whether the cursor block will be re-fetched (rollbackPointReprocessed). When it will, the four stores delete from that slot inclusive. This also covers the first restart after upgrading, when the cursor block's rows still have random ids.
2. Deterministic ids plus upsert. The id is a name-based UUID (v5) of the row's natural key, and rows are written with a jOOQ batch upsert on the existing id primary key, so a re-processed row overwrites itself:
   • transaction_metadata: tx_hash, label
   • assets: tx_hash, unit (asset_name is a decoded, sanitized name and can repeat)
   • transaction_scripts: tx_hash, purpose, redeemer_index (one row per redeemer)
   • mir: tx_hash, cert_index, credential (null for pot-to-pot transfers)

No schema change or migration. Existing rows keep their random ids and new rows get deterministic ones, so existing databases need no resync. On MySQL the id is bound as binary(16), as Hibernate writes it. metadata and mir are added to the jOOQ codegen modules.

Rows already duplicated by earlier restarts are not cleaned up. That needs a one-off dedupe per table.

Tests

• UUIDUtilTest: deterministic, version 5 with the IETF variant, length-prefixed parts don't collide, null is distinct.
• One storage test per store: saving the same rows twice leaves one row per key with updated values. The assets test uses two units sharing one asset_name; the mir test uses a null credential.
• Rollback processor tests for the inclusive delete, and StartServiceTest for the reprocessed flag.
• The store tests run on H2. The upsert SQL was rendered for PostgreSQL (ON CONFLICT (id) DO UPDATE), MySQL (ON DUPLICATE KEY UPDATE) and H2 (MERGE), but it has not yet been run against a real PostgreSQL or MySQL.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JKakmKURLn4uc33hgrz2hF

[satran004]

Merge note for #1313 and #1266 (found while combining the #1328 PRs for the re-test)

• fix(stores): stop re-processed blocks from duplicating metadata, assets, script and MIR rows #1266 sets RollbackEvent.rollbackPointReprocessed = true on a range-fetch start, because the range fetch delivers the cursor block again. Stores with generated keys (assets, metadata, MIR, scripts) then also delete the rows at the cursor slot, expecting the block to be written again.
• fix(core): never skip a block silently after a restart or a storage failure (#1308) #1313 (updated for Auto-recovery fault-injection test: what was tested, findings and fixes #1328) now skips that re-delivered cursor block when it is already processed. It is processed only when the start point is a fresh start.

Merged together as they are, those stores would lose the cursor block's rows on every restart in range mode. The combined branch resolves it in StartService like this:

.rollbackPointReprocessed(fetchRange && processedBlockNumber == null)

processedBlockNumber is the start block number, which #1313 passes to BlockFetchService only when the start point was really processed. Whichever of the two PRs merges second needs this change.

[satran004]

Merge note for #1330 and #1266: StartService now gets the tip with tipFinderService.findTip(timeout) instead of getTip().block() (#1330). StartServiceTest, added in #1266, stubs getTip(). Whichever of the two PRs merges second needs this one-line change in StartServiceTest:

when(tipFinderService.findTip(anyLong())).thenReturn(new Tip(new Point(slot, "tip_hash"), 10_000_100L));

It is already applied on the combined test branch test/recovery-combined (commit 8fef4cb).

[satran004]

Fault-injection re-test result

We ran the same 104 fault scenarios again on preprod (benchmark-vm): 43 during the initial sync and 61 at the tip. This time the build had all the fix PRs together: main + #1330, #1331, #1313, #1332, #1271, #1333, #1266 (branch test/recovery-combined).

• All 104 scenarios recovered on their own. None needed a manual restart. In the first run, 7 got stuck.
• No duplicate rows.
• Missing blocks: only the 2 that B04 skips on purpose. B04 sends an undecodable block with continue-on-parse-error=true.
• address_utxo_unspent is exact: 0 missing and 0 extra rows, compared with address_utxo minus tx_input.

Details and the full list of findings: #1328

This PR in the test

• No duplicate rows in any table across all 104 scenarios. main wrote duplicates in 27 of them (Range sync: block re-delivered after reconnect is processed twice #1319).
• One new replay problem, in the pool table. It doesn't come from UUIDs, so it is outside this PR:
  • When a block with a pool's first registration is processed again, the registration is rewritten as an UPDATE, and its deposit moves to a later epoch.
  • It is fixed separately in fix(staking): replaying a block keeps a pool registration a registration #1335.

[sonarqubecloud]

Quality Gate failed

Failed conditions
D Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[satran004]

Updated after an external review of the 2.0.x backport #1345: 75c33ff, 652e1d8. Each finding, its verdict and its test are in the reply on #1339.

[satran004]

Verdict: APPROVED

reviewer1 — original-PR review at 652e1d8208fc2d670b95d827420ca08868e04831.

F1 and F2 from #1345 are resolved here: MIR IDs distinguish key/script credentials, and the script batch owns a transaction. I checked the main-specific metadata writer: it retains tx_index on insert and replay.

Keep rollbackPointReprocessed(fetchRange && processedBlockNumber == null) when merging with #1313. The SHA-1 UUID note remains accepted for these public-data identifiers; the Sonar gate still needs disposition. Old random-ID duplicates still require deduplication.

The numbered findings refer to the counterpart review of #1345. No additional blocking finding remains.

Validation on combined main: core 244 passed, 1 skipped at d9b1d37282351992da8f45a85e0e3dbe62e5e1e2; eight other relevant suites 197 passed at f0579f9a5f42ae98694d8f35cd0c998295cc1c20, with zero failures/errors in these successful runs. Exact commands, integration resolutions and scope. These are combined-build results, not a separate standalone run of this PR.

[satran004]

Fault-injection rerun on main with all seven fix PRs at their approved heads (test/recovery-combined d9b1d3728): 104 of 104 scenarios recovered, with no duplicate rows and no unexpected missing blocks. The full report is on #1328: #1328 (comment)

For this PR:

• Unpatched main flagged duplicate rows in 77 of 104 scenarios: scripts in 77, assets in 54, metadata in 6.
• Now there are no duplicate rows in any scenario. assets and transaction_metadata match the reference, and transaction_scripts differs only where it depends on the block B04 skips on purpose.

The baseline is unpatched main at 6836c4dd6, run on the same matrix.