| Filename | Latest commit message | Latest commit date |
|---|---|---|
3aa4036e3c
Some checks are pending
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (push) Waiting to run
An owner session may acknowledge an entry once every follower it named at its first such entry holds it on disk, and upload it to the store after. It creates log/<node>/<session>/open and then reads for a seal; a taker creates the seal and then reads for open, so one sees the other. The taker seals every follower it can reach, which then refuses the session for good, uploads what they hold and marks the session recovered before it restores; only the tip epoch's owner can hold what the store does not. Followers keep framed logs (length, body, four bytes of BLAKE3) in a directory of their own and answer authenticated peer requests (BLAKE3 keyed with fleet/peer-key, a one-minute window) under /.jcp-fleet/ on the node's listener. The owner of a record removes, below its epoch, the bases off its chain and the entries its chain clips, its own base's clip included; any node removes the marks of sessions already recovered and never an unrecovered seal; a restore that finds a listed object gone lists again. jcp-gateway --fleet acknowledges through up to two followers named from the live leases, keeps what it follows in --fleet-data, uploads continually and collects each minute. In the two-process test the owner's receipts are on its follower and not in the store when it is killed, and the takeover has them only by sealing it. Every order of an owner acknowledging through a follower beside a takeover (1091 at three preemptions) and of a collection beside a takeover (2494, 333 of them reading a listed object already collected) loses nothing; mutants.py removes each of 15 rules and the tests fail for every one. Co-Authored-By: Claude Opus 5.5 <[email protected]> |
||
| .. | ||
| http_binary.rs | ||
| http_pack.rs | ||
| stdio_binary.rs | ||
| upstream_tree.rs | ||