Akka 8508
Akka.NET issue 8508, found again from the commit before its fix
Summary
On Akka.NET from before the fix for issue 8508, a search found a failing replay code on its first try, and 3 replays gave the same verdict. Molina shrank the failure: the nodes ran 83 s at first and 13 s in the smallest version that still broke it. I wrote the failure schedule from this bug's own mechanism, so it says nothing about finding unknown bugs.
The full experimental record
What I ran
A seeded search, run on the commit before the fix for issue 8508 with a reconnect timeout set on the client, found a seed on which the client stopped at 30.1 s. A behaving client stops no earlier than 32.6 s, which is its last reply at 2.6 s plus the reconnect timeout. A stop that early is how a stray reconnect timer shows. That was seed 1 (the first try at that seed was set aside, see the conditions). The search tried the first seed only.
What it shows
MIGHT. In 4 of 4 runs of seed 1 of the issue 8508 scenario on the commit before its fix, the cluster client stopped before the earliest a behaving client stops.
What it does not show
The scenario was written from this bug's own mechanism. Its range of cuts was set from a connect time measured in an earlier run of this same seed. According to the repository's notes (docs/readiness-bar.md), the first research run of the scenario drew its cuts from an assumed connect time and did not stop the client, and the range was set after that run. According to the same notes, that same seed had already stopped the client in research runs before the gate ran, with the final cuts. This page does not carry the outputs of those runs. So the find on the first seed repeats what the scenario was built to show. It says nothing about how often a search would find a bug, or a bug nobody has described.
That a search finds a bug nobody has described, or one for which nobody wrote a scenario.
That the bug shows with Akka's default settings: the scenario sets a reconnect timeout on the client, and the release leaves it off.
Conditions
The first output is a committed-tree ledger PASS, and the second, of the whole gate made again, is a committed-tree ledger PASS.
Where it comes from
evidence/20261103T221543Z-readiness-rediscovery.out
This page is the short form of the record. The finding and its limits come first, and I left out what did not fit.