Repository navigation
Conversation
…sync that is not running - Flyway retries the first database connection (30 retries, up to 10 s apart), and Hikari no longer fails at pool creation. The app no longer exits when it starts before Postgres is ready, for example after a host restart (fault-injection scenario J09, #1328). - Stopping a range fetch or chain sync that was never started or is already closed logs one warning line instead of a stack trace (#1314). Part of #1328. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… stop errors
Review: Spring Boot resolves Flyway's {vendor} location through the DataSource
before Flyway's connect-retries apply, so the retries never ran. Replace them
with a small BeanPostProcessor that retries a connection right after the
DataSource is created (store.db.startup-wait-seconds, default 300, 0 = off).
Only the NullPointerException yaci throws for a session that was never started
gets the one-line log; other stop errors keep their stack trace.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
satran004
added
3.0.0-beta6
|
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: No issues found in this first check. Not tested: Code was read only; builds, tests, and database-startup fault scenarios were not run. |
Fault-injection re-test resultWe 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
Details and the full list of findings: #1328 This PR in the test
|
Review: the deadline was only checked after a failed attempt, and the pause before the next attempt was always 5 s. With store.db.startup-wait-seconds=1 and a refused connection the wait took about 5 s and made a second attempt after the budget was already used up. Now the pause is capped to the time left, and no attempt starts once the budget is used up. A single getConnection() that hangs is still bounded by the pool/driver connection timeout, not by this wait; the class comment says so. The clock and sleep are injectable so the tests check the timing without waiting. Added tests for a 1 s budget, the capped last pause, an attempt that uses up the budget, a real-clock 1 s budget, and interruption. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MJrQUCWhJpLCQR5Asv7nDb
The last pause is capped to the time left, so it ends at the deadline. Try once more then instead of giving up right after the pause, so a database that comes up within the budget is still used. No attempt starts after the deadline. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MJrQUCWhJpLCQR5Asv7nDb
|
Updated after an external review of the 2.0.x backport #1346: 76cc063, 08b7df4. Each finding, its verdict and its test are in the reply on #1339. |
The last pause ends at the deadline, but the thread can wake up late (scheduling, GC, a suspended process), and the next attempt then started after the deadline. Check the clock after the pause: an attempt at the deadline is still made, a later one is not. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MJrQUCWhJpLCQR5Asv7nDb
|
|
Verdict: APPROVED reviewer1 — original-PR review at F1 from #1346 is resolved at this head. The startup wait caps its pause and checks the clock after waking, so a retry at the deadline is permitted and one after it is rejected. The implementation and deadline tests match the approved backport. The numbered findings refer to the counterpart review of #1346. No additional blocking finding remains. Validation on combined main: core 244 passed, 1 skipped at |
|
Fault-injection rerun on For this PR:
The baseline is unpatched |
Part of #1328.
Problems
restart: unless-stopped), but the standalone jar and other process managers don't.What changes
DatabaseStartupWait. Right after the DataSource is created, and before anything uses it, it tries to connect every 5 s for up tostore.db.startup-wait-seconds(default 300;0turns it off), logging a short line each time. If the database is still down after that, the startup fails as before.connect-retries. Codex's review showed Spring Boot connects to resolvedb/store/{vendor}before those retries apply, so they never ran. The wait is now on the DataSource itself.Tests
0turns it off, and other beans are left alone.🤖 Generated with Claude Code