Cross-process lease lock with generations (§3.6, §10.7.4, D57): §12.1 entity, store ports, engine wiring, conformance kit #109
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Sub-issue 1 of #87 (decided 2026-08-21, D57): a lease_locks row per durable store — holder id, expires_at, monotonic generation — acquired by a CAS write inside the store's own transaction, renewed by the holder, expiring for crashed holders (bounded recovery). The generation bumps on every hand-over so a process that lost and regained the lease invalidates its in-memory caches (rust-sdk cross_process_lock shape). Scope: §12.1 entity row + §10.7.4 detail (spec change first), FactStores/CryptoStore/media-cache port methods, in-memory + sqlite implementations (migration), session wiring (acquire before the sync loop's first write; renew; lost-lease → typed state), §10.11 conformance-kit cases incl. crash-expiry and generation detection. Tests reference CR-1/CR-17.
Delivered in
0863fc1(CI build #764 green, both phases incl. the MAS e2e). LeaseStore port + InMemoryLeaseStore + SqliteLeaseStore (schema v12), 10-case conformance kit (in-memory + sqlite jvm/android), CrossProcessLease coordinator (acquire-with-bounded-wait → StoreLeaseUnavailable, renew, observable Held/Lost + stale-generation, best-effort release), opt-in connect(leaseStore=…) wiring, KatrixException.StoreLeaseUnavailable, spec §12.1 + §10.7.4 (D57). Deferred to #112 (where it is exercised): halting the sync loop's writes on LeaseStanding.Lost — currently surfaced as observable standing; the two-process on-device run drives it end to end.