nothing works yet. the design is written down and the code is catching up. the repo is private until it does something.
distributed systems fail on timing, and the timing is different every run. a test passes a hundred times, fails once, and passes again, and you never find out whether the bug got fixed or just got lucky.
diaspore pulls every source of that randomness into one place and drives it from a single seed. same seed, same run, every time. a flaky failure becomes an address you can go back to.
how it works
it's one Go binary. the system under test is a set of separate programs, called florets, that talk to diaspore with one line of JSON in and one line out. any language works.
diaspore owns everything a floret would normally get from the outside world:
- time is virtual and only moves when diaspore says so, so a two-minute scenario runs in a fraction of a second.
- the network is simulated. every message goes through diaspore, which decides when it arrives, or whether it does at all.
- faults like delays, drops, duplicates, crashes, and partitions come from rules in a config file.
- client load comes from the same seed, so the workload replays too.
it sends one event to one floret, waits for the reply, then moves on. nothing races, so two runs can't differ.
finding the failures
diaspore dandelion sweeps thousands of seeds across every core and reports the
ones where a checker caught something, like an acknowledged write going missing
or a history that isn't linearizable.
each failure is saved as a .pappus file: the seed, the full config, a hash of
every floret, and the expected trace hash. hand someone that file and you've
handed them the whole bug.