chore: bump yaci-store to 2.0.2.1

[matiwinnetou]

What

Bumps the yaci-store dependency in yaci-indexer/pom.xml from 2.0.1 → 2.0.2.1.

- <yaci-store.version>2.0.1</yaci-store.version>
+ <yaci-store.version>2.0.2.1</yaci-store.version>

2.0.2.1 is a patch on top of 2.0.2, so this PR pulls in the changes from both releases.

Upstream changes

2.0.2.1 — auto-restart counter is now a sliding window (indexer keeps retrying)

• fix: reset auto-restart counter on a sliding window — fix: reset auto-restart counter on a sliding window  bloxbean/yaci-store#998 (external contribution by @DanchuoZhong), backported to the 2.0.2.1 release via [backport] fix: reset auto-restart counter on a sliding window  bloxbean/yaci-store#1008.

This is the reason for the patch. Previously the auto-restart attempt counter (restartCount) was a lifetime cap: once it hit store.auto-restart.max-attempts, the indexer logged "Max restart attempts reached. Manual intervention required." on every health-check interval and never retried again until the process was manually restarted — even long after the underlying node/connection outage had recovered. The only reset path required 5 minutes of confirmed healthy block reception but gave up after a 10-minute hard timeout, so any outage longer than ~10 minutes left the counter permanently exhausted.

For Rosetta this was exactly the failure we hit before: after a burst of connection drops the yaci-indexer would give up and stay stuck until someone restarted the container.

The fix turns the counter into a sliding-window rate limit: if no restart has been attempted within the restart window (default 10 minutes, now configurable via store.auto-restart.window-ms), the counter resets so a later, unrelated outage is treated as a fresh incident and recovers automatically. max-attempts is preserved as a per-window limit to still guard against restart storms. The exhausted-attempts log was also downgraded from ERROR to WARN since recovery is now automatic.

Net effect: the indexer keeps trying to reconnect/restart and self-heals from transient node or socket outages instead of giving up permanently.

2.0.2 — governance hard-fork SPO abstain tally

Also included, since 2.0.2.1 builds on it:

• fix(governance): correct hard fork SPO abstain tally — fix(governance): correct hard fork SPO abstain tally bloxbean/yaci-store#989
  • In VoteTallyCalculator, SPO stake delegated to the auto-abstain DRep was being added to the abstain tally even for hard-fork-initiation actions. For HARD_FORK_INITIATION_ACTION that stake must not count as abstain (it effectively counts as No). One-line logic fix plus expanded unit tests; touches only the aggregates/governance-rules module.

Upstream release guidance (2.0.2)

• Mandatory for deployments where ledger-state is enabled or the adapot / governance modules are used — without it, governance / ledger-state data may be computed incorrectly. Recommended for all others.
• Preprod PV11 note: fixes an issue during the Protocol Version 11 hard fork on Preprod. A Preprod instance that has already crossed PV11 must either roll back to a pre-PV11 epoch (admin CLI) and resync, or resync from scratch.

Scope / risk

• Dependency version bump only. No source, config, or API changes.
• The auto-restart sliding-window fix hardens indexer resilience against transient node/socket outages — no behavioural change under normal steady-state operation.

[github-actions]

✅ Preprod Tests: PASSED

📊 View Detailed Test Report

🔗 Action Run #409

Tests run against preprod network with live blockchain data

[github-actions]

✅ Preprod Tests: PASSED

📊 View Detailed Test Report

🔗 Action Run #412

Tests run against preprod network with live blockchain data