Skip to content

fix: fail-fast on the archive-replay error hot-loop (P1.3, match#35)#55

Merged
emrebulutlar merged 1 commit into
mainfrom
fix/replay-hotloop-failfast
Jul 4, 2026
Merged

fix: fail-fast on the archive-replay error hot-loop (P1.3, match#35)#55
emrebulutlar merged 1 commit into
mainfrom
fix/replay-hotloop-failfast

Conversation

@emrebulutlar

Copy link
Copy Markdown
Member

Part of #35 (P1.3-iv). Both replay-loop incidents (2026-07-02, 2026-07-04) threw the byte-identical ArchiveException thousands of times while the node sat wedged forever. The Aeron error handler now tracks the consecutive-identical-error streak (class + message signature); at 200 consecutive identical errors it signals the barrier and halts (exit 2) with a loud FAIL-FAST log naming the signature and pointing at reseed/recovery. Different errors reset the streak — healthy operation never repeats one exact error 200 times in a row.

Reuses the existing driver-death exit machinery (barrier + backstop halt + FATAL_EXIT_STARTED once-guard). Companion admin-gateway PR adds the lag guard that prevents the stranding in the first place.

🤖 Generated with Claude Code

The 2026-07-02 and 2026-07-04 incidents each threw the byte-identical
ArchiveException ("replayPosition ... does not point to a valid frame")
thousands of times from Election.followerLogReplication while the node sat
wedged indefinitely — silent before the truthful status API, DEGRADED-forever
after it, but never terminal.

The Aeron error handler now tracks the consecutive-identical-error streak
(signature = exception class + message, which stayed byte-identical across
5,400+ throws in the incidents). At 200 consecutive identical errors it
signals the shutdown barrier and halts (exit 2) with a loud FAIL-FAST log
naming the signature and pointing at reseed/recovery — a crashed node the
process manager can count and the operator can see, instead of a spinner.
Any different error resets the streak; healthy operation never repeats one
exact error 200 times in a row.

Companion guard (refuse snapshot/housekeeping while a member is down or
lagging — the stranding mechanism itself) lands on the admin-gateway.

Part of match#35 (P1.3).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant