Akka.NET issue 8508, its plan shrunk

What I ran

The plan the seed drew, a partition from 3,509 ms to 63,509 ms of virtual time with nodes running 83 s, was shrunk to a partition from 3,509 ms to 17,509 ms with nodes running 13 s, in 27 questions asked of worlds.

What it shows

MIGHT. The cluster client stopped before the earliest a behaving client stops, seen once in the shrunk plan of seed 1 of the issue 8508 scenario on the commit before its fix and then in 3 of 3 re-runs.

What it does not show

The output gives one summary line for the one-step neighbours and no verdict for each: it says that none of them stopped the client.

This issue is a known bug with a fix, and the run is of the commit before the fix. The scenario was written from this bug's own mechanism, and its range of cuts was set from a connect time measured in an earlier run of this same seed.

That the bug shows with Akka's default settings: the scenario sets a reconnect timeout on the client, and the release leaves it off.

Two runs of the gate output were set aside because a world's counted stop was refused, and each was made again.

According to the repository's source (src/campaign/ComposeShrink.fs), the product's shrinker, molina campaign --compose, takes an isolate and a stop and keeps the chance dials as they were drawn. This shrink was made by the gate's own code. No command reduces a lying-flush file or a window of virtual time on a customer's file, so a customer receives a smallest set of failures only where the shrinker can reduce the failure, and what it returns is the smallest it found against the runs made.

Conditions

The ledger row of this gate names its kind as claim and does not list the claim conditions, so the result is rated as screening. Made on one machine, and the saved output does not name its processor.