[satran004]

Backport of #1335 to release/2.0.x. Tracked in #1339.

What it fixes: see #1335. The backport changes the same code in the same way.

How it was made: The commit of #1335, no changes. Commits are cherry-picked with -x, and the changed lines were compared one by one with #1335.

Checks: 32 stores/staking tests pass, including the 5 replay tests.

Fault-injection run: the same scenarios as #1328 are running on release/2.0.x with all the backports. The results will be posted here and in #1339.

🤖 Generated with Claude Code

[beanbot-gh]

Initial automated review · Aster

Hi @satran004, thanks for the PR! 🙏 This is an automatic first check by an AI reviewer. It does not replace maintainer review and may be wrong.

Reviewed commit: 03274d87164b9cd9a99075ecebada20650e7f03d

Issues found:

• stores/staking/src/main/java/com/bloxbean/cardano/yaci/store/staking/storage/PoolStorage.java:24 — An existing custom PoolStorage bean can throw AbstractMethodError on the first pool registration after a 2.0.x upgrade because this new method is required.
• stores/staking/src/main/java/com/bloxbean/cardano/yaci/store/staking/processor/PoolStatusProcessor.java:116 — If a failed block leaves its registration in the cache, retrying the block can count the same certificate twice in StakingDepositEvent even though only one row is saved.

Not tested: I reviewed the code and CI without running the build, tests, or a failed-block replay.

[satran004]

Fault-injection result on release/2.0.x

The same scenarios as #1328 ran on plain release/2.0.x and on release/2.0.x with all 8 backports (#1340–#1347). With the backports:

• all 104 scenarios recovered on their own, with no manual restart (plain 2.0.x: 6 stuck);
• no duplicate rows (plain 2.0.x: 31 scenarios);
• only the 2 blocks that B04 skips on purpose are missing (plain 2.0.x: 9 blocks).

Full results: #1339.

This PR in the run: no replayed block held a pool registration in this run, and the pool table matched the reference on both builds. The fix is covered by its 5 tests.

[beanbot-gh]

reviewer1 — review of 03274d87164b9cd9a99075ecebada20650e7f03d

Changes requested on two points. The new strict (slot, txIndex, certIndex) predicate correctly excludes the certificate being replayed and later registrations. The five tests cover successful row replay and ordering, including re-registration after retirement.

1. [P2] Make the cached event path replay-safe too. PoolStatusProcessor.java:114–117 now correctly classifies each copy of the same first certificate as a REGISTRATION. But poolRegistrationsCache survives a failed block and handleRollback() deletes database rows without clearing that cache. If a listener fails after processPoolRegistrationEvent() and before successful pre-commit completion, replay queues the certificate again. The next pre-commit iterates both copies and publishes registration count 2 while the natural-key database row remains 1. I compiled the actual processor source and reproduced distinct_saved_rows=1, deposit_registration_count=2 with a stub storage implementation modeling the new before-certificate query. This affects StakingDepositEvent consumers/plugins; I am not claiming a measured double charge in the built-in adapot calculation. Clear/discard failed-session cache entries and deduplicate by certificate identity. Test through processPoolRegistrationEvent → failure/rollback → replay → PreCommitEvent, including the emitted event, rather than only calling handlePoolRegistration() directly.

2. [P2] Address custom-storage compatibility for this stable-line backport. PoolStorage.java:24 adds a required abstract method to the replaceable storage interface. An existing separately compiled PoolStorage bean, supported by @ConditionalOnMissingBean, can still load but fail with AbstractMethodError on the first registration. Provide an explicit compatibility/capability strategy or clearly require provider upgrades as part of the release contract; do not silently fall back to the old query, which would restore the replay bug. Add a compatibility check for a provider built against the previous API.

The VM report explicitly says no replayed block contained a pool registration. Its matching pool table therefore does not validate this fix's trigger. Keep #1337's retirement-ordering issue tracked separately, and distinguish prevention of future replay damage from repair of already misclassified historical rows.

Validation: exact-head source/query/test inspection and the focused compiled processor harness above. No full staking suite, Spring transaction integration, or VM rerun.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[satran004]

Thanks, reviewer1. Handled as follows:

1. Cache: it replaces an earlier copy of the same transaction (one event per transaction, so two pools registered in one block are both kept). All caches are cleared on rollback. The tests go through processPoolRegistrationEvent, rollback, replay and PreCommitEvent.
2. Custom PoolStorage: the new method is a default that throws a clear error naming it, with no silent fallback. There is also a note in the upgrade section of release/2.0.x: backport the auto-recovery and data-correctness fixes from the fault-injection test #1339.

Commits: 0fb6071, 72b8c9f, 776f9eb here, 15f7a3d, 132f4fb, 1e85144 on #1335.

The fixes were made in #1335 first and cherry-picked here. Each finding, its verdict and its test are in the reply on #1339. The fault suite is running again on the updated combined build.

[satran004]

Verdict: APPROVED

reviewer1 — round 2. Reviewed 776f9eb5428e1609f19b721e8d378added6796cf, compared with 03274d87164b9cd9a99075ecebada20650e7f03d.

Both original findings are resolved.

Finding	Status	Reason
F1 [P2]	Resolved	Cache replacement is per transaction, preserving separate registrations in one block; rollback clears all four pending caches. Replay/rollback/multiple-transaction tests cover the reported failure.
F2 [P2]	Resolved	The default method gives old providers an explicit failure instead of a linkage error or silently incorrect fallback. The upgrade notes require providers to implement the ordering-aware query.

This is an explicit provider upgrade requirement, not transparent behavioural compatibility. I accept that documented choice.

Validation: seven module suites on isolated combined commit 121ee4599fcdc41226239b9195ce45daa47cfc9d: 366 passed, 1 skipped, 0 failures/errors (core: 219 passed, 1 skipped). This is combined-build validation, not a separate run on every backport.

Exact command

JAVA_HOME=/Users/satya/.sdkman/candidates/java/21.0.3-tem ./gradlew :components:core:test :components:common:test :stores:assets:test :stores:metadata:test :stores:script:test :stores:mir:test :stores:staking:test --no-daemon --console=plain

No implementation changes made by this review. The updated VM fault-suite results are still pending. This verdict covers the reviewed head only.

[satran004]

Fault-injection rerun on 2.0.x with all eight backports at their approved heads (test/recovery-combined-2.0.x bbac1a25a): 104 of 104 scenarios recovered, with no duplicate rows and no unexpected missing blocks. The full report is on #1339: #1339 (comment)

For this PR:

• pool, pool_registration, pool_retirement, delegation and stake_registration match the reference exactly, in row counts and content, after 104 scenarios of restarts, rollbacks and replays.

The unpatched baseline is release/2.0.x (b2x), run on the same matrix.