AshArcadic.ReplicantCheckpoint (AshArcadic v0.2.0)

Copy Markdown View Source

use AshArcadic.ReplicantCheckpoint, domain: MyApp.Domain, client: MyApp.ArcadicClient injects the ArcadeDB-resident checkpoint vertex resource (label :ReplicantCheckpoint) — one row per replication slot, holding the last durably-applied last_commit_lsn watermark — plus the for_slot/1 and upsert_lsn/2 seam helpers the sink's apply step (AshArcadic.ReplicantSink) calls directly.

The sink upserts this row in the SAME Ash.transaction as the mirrored data writes, which is what gives effect-once (dup = 0) semantics: the watermark advance and the data writes commit atomically in one ArcadeDB session.

The client: opt MUST resolve to the SAME ArcadeDB database as the mirrored resources. This resource is deliberately non-tenant-scoped (no multitenancy block) — nothing here verifies the single-database precondition (unlike AshArcadic.Replicant's mirror-resource verifier: this is not a mirror resource). A client: pointed at a different database than the mirrored resources breaks the same-transaction guarantee — the checkpoint upsert becomes a cross-database write, which AshArcadic.Transaction.resolve_conn fails closed on (:cross_database_transaction) rather than silently splitting the commit. The consumer is responsible for wiring this correctly.

Seam-lock (design §12 "checkpoint writes seam-only"). Ordinary writes are forbidden by an Ash.Policy.Authorizer policy (forbid_if always()). The injected for_slot/1 and upsert_lsn/2 helpers are the only sanctioned read/write path — they bypass the policy with authorize?: false. Any other caller (e.g. a bare Ash.create/2 without authorize?: false) is rejected.