[satran004]

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

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

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

Checks: 107 components/core tests pass; admin compiles.

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: dd6244715f6698e13705d260eea34f90f5e8f5e3

Issues found:

• components/core/src/main/java/com/bloxbean/cardano/yaci/store/core/configuration/DatabaseStartupWait.java:57 — With a one-second startup wait, a refused connection can still trigger a five-second sleep and another connection attempt after the deadline. Could we check the remaining time before sleeping and retrying?

Not tested: I reviewed the code and CI without running the build, tests, or a database outage scenario.

[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: J09 (app and Postgres killed together, as in a host crash) during the initial sync: on plain 2.0.x the app exited because it started before Postgres, and needed a manual start. With this fix it waited for the database and recovered in 50 s.

[beanbot-gh]

reviewer1 — review of dd6244715f6698e13705d260eea34f90f5e8f5e3

One [P2] fix requested: enforce the configured retry deadline before sleeping and before the next attempt. DatabaseStartupWait.java:46–57 checks the deadline only after a failed connection attempt, then always sleeps five seconds. With store.db.startup-wait-seconds=1 and immediately refused connections, I compiled and ran the exact PR source and measured 5,004 ms and two connection attempts. The second attempt begins after the budget has already expired and can add the pool/driver's entire connection timeout.

Calculate the remaining budget, cap the sleep to it, and check expiry before starting another attempt. Also make clear that an in-flight getConnection() needs its own bounded pool/driver timeout; the current deadline cannot interrupt a connection attempt that never returns. Add expiry and interruption tests alongside the existing retry-success/disabled tests.

The hook's placement before consumers use the datasource is appropriate for the reported startup failure, and the J09 recovery in 50 seconds is useful evidence that this fixes the tested host-restart ordering. I found no additional blocking issue in the stop-log changes.

Validation: exact-head source/test inspection and a small compiled harness with a refusing stub datasource. No real database outage or full-suite rerun.

[satran004]

Thanks, reviewer1. Handled as follows:

• The pause is capped to the time left. The last attempt starts at the deadline, so a database that comes up within the budget is used; no attempt starts after the deadline.
• The javadoc says a hanging getConnection() is bounded by the pool timeout.
• New tests: expiry, a capped last pause, interruption (fake clock).

Commits: 9988540, 86d475f here, 76cc063, 08b7df4 on #1333.

The fixes were made in #1333 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: CHANGES REQUESTED

reviewer1 — round 2. Reviewed 86d475fc552a958ac74cbe773ba3799780a4750b, compared with dd6244715f6698e13705d260eea34f90f5e8f5e3.

F1 [P2] is partially resolved. Capping the pause fixes the original five-second oversleep for short budgets. Allowing an attempt exactly at the deadline is acceptable, but the implementation still starts attempts after it.

F1 [P2], completion of the original finding. DatabaseStartupWait.java:84: after sleeping, the loop retries without checking the clock. Thread.sleep(remaining) can resume late because of scheduling, GC or process suspension. That late attempt can incur another connection timeout.

A deterministic probe against the actual class uses a 1,000 ms budget and a sleeper that resumes 1,000 ms late. Output: deadline_ms=1000, attempt_start_ms=[0, 2000]. The source is identical on this head and the tested combined commit. The existing fake-clock tests resume exactly on time, so they miss this.

Please recheck the clock before a retry and stop when it is greater than the deadline; equality can retain the requested final attempt. Add one oversleep test. No larger retry redesign is needed.

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.

[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]

Verdict: APPROVED

reviewer1 — round 3. Reviewed 22aaa9ead98c72db212e7f94966062e6dc5fc8c1, diffed from 86d475fc552a958ac74cbe773ba3799780a4750b.

F1 [P2]: Resolved. The post-sleep clock check rejects a retry after the deadline while allowing equality. The new oversleep regression covers the missing case. No further change requested.

Validation on this exact head in an isolated checkout: 10 tests passed, none failed or skipped:

JAVA_HOME=/Users/satya/.sdkman/candidates/java/21.0.3-tem ./gradlew :components:core:test --tests com.bloxbean.cardano.yaci.store.core.configuration.DatabaseStartupWaitTest --no-daemon --console=plain

The independent round-2 oversleep probe now reports deadline_ms=1000, attempt_start_ms=[0] (previously [0, 2000]). No implementation files changed by this review. Approval covers this head only.

[satran004]

Author reply: round r2 · head 22aaa9e

Finding	Change	Where
F1 [P2]	After the pause, the clock is checked again. An attempt exactly at the deadline is still made; an attempt after it is not. New test: a pause that ends 1 s late leads to no second attempt.	DatabaseStartupWait.waitFor; DatabaseStartupWaitTest.noAttemptAfterAPauseThatEndsLate

Made on #1333 first (b3726b0), then cherry-picked here. Thanks for the approval.

[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:

• The Postgres scenarios all recovered: D01–D11 in both phases (Postgres down, frozen or partitioned, among others), J09 (app and Postgres killed together) and C07 (fresh JVM while the node refuses).

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