Akka.NET, a node joining a cluster, run again from a snapshot

What I ran

NodeUpSpec, Akka.NET's own multi-node test of a node joining a cluster, was restored from 12 snapshots into worlds and wrote byte-identical node logs in 36 of 36 worlds on an idle host and in 36 of 36 on a loaded host. Byte-identical here means the worlds restored from one snapshot wrote the same node logs, so the worlds of a snapshot agree with the others of their snapshot.

The singleton cluster spec, run the same way on the same day, wrote byte-identical node logs in 36 of 36 worlds idle and in 33 of 36 loaded. Three worlds of the loaded run were set aside because their job shared a core with another process, and are not counted among those 33. The loaded run graded 11 of 12 snapshots.

Outputs of the same gates from a committed tree exist: NodeUpSpec wrote byte-identical node logs in 36 of 36 worlds idle and in 36 of 36 loaded (a committed-tree ledger PASS), and the singleton spec in 36 of 36 idle and 36 of 36 loaded (a committed-tree ledger PASS). The thread race result states them.

What it shows

UNRATED. SageTech cannot tell how this was produced: the repository had uncommitted changes when it ran.

What it does not show

Both ledger rows of these outputs say the repository had uncommitted changes when they ran (their dirty field is true; the tree_state field of each row, which is about the files the gate reads, disagrees), so the page does not rate the result above UNRATED: it does not rate a result from such a row.

That exact replay holds for another spec, a larger cluster, another snapshot point or another machine.

Conditions

The worlds were restored from one snapshot each, at the count margin the gate asks for, with the TSC hidden. The NodeUpSpec output is an uncommitted-tree ledger PASS and the singleton output is an uncommitted-tree ledger PASS.