Skip to content
Tasuku

Idempotency & List-Members Repositories

Two repositories underpin reliable sync and sharing: idempotent replay and list membership.

Idempotency

Section titled “Idempotency”

createIdempotencyRepository(db) (src/db/repositories/idempotency.ts) backs the idempotencyKeys table. Each queued client mutation carries a stable Idempotency-Key; on replay the server records/looks up the key so a re-sent mutation does not double-apply. This is what makes outbox replay safe after offline periods or retries (constitution §7.14.3; see Offline Outbox & Optimistic Writes).

List members

Section titled “List members”

createListMembersRepository(db) (src/db/repositories/list-members.ts) backs the listMembers table — the join between Lists and the Users they’re shared with (Members). Domain rules (Product Brief §5.2):

  • Only the List owner changes memberships (add/remove Members); a List can only be shared with registered Users.
  • listMembers carries per-viewer order + group for shared Lists, so each Member arranges a shared List in their own sidebar independently of the owner (spec 011).
  • Membership changes drive notifyMembership(...), which signals both the list’s users and the user whose access changed; revoked access is evicted client-side via evictRevoked(...) (see DB Schema & Notify-Affected, Sync-Core Reconcilers).
  • Assignment (spec 012) depends on membership: a Task may be assigned only to a Member; removing a Member clears their assignments.

Related: DB Schema & Notify-Affected, Offline Outbox & Optimistic Writes, Worker API & Clerk Auth.