im: give the IM delivery layer its own database (shape B) #47

Merged
PerishFire merged 1 commit from im-own-database into main 2026-07-21 08:38:40 +00:00
Owner

Operator chose shape B: im is a downstream consumer with its OWN database. santi-im now exposes an ImStore that opens/owns its own SQLite file (im_inbox + im_participants); those tables leave santi's schema; santi keeps only reply_outbox (producer side). SantiStore holds an ImStore (at .im) and delegates, so ops/service/api call sites are unchanged. Cross-store paths split at the boundary: receipt im_deliveries = santi turn_ids + im deliveries_for_turns; manual reply = santi resolves participant + im enqueues. Auto reply flows reply_outbox -> dispatch -> im.deliver_reply into im's db (at-least-once + idempotent). Per '全部清零', no cross-db migration: im db starts empty, santi's im tables dropped. Obsolete v26 test removed; delivery-failure trigger targets im's db. 0 faults, core 0, 48 test groups green. Remaining purity: ImStore still inside SantiStore (core still crate-deps im); moving to api is the final step. window separate.

Operator chose shape B: im is a downstream consumer with its OWN database. santi-im now exposes an ImStore that opens/owns its own SQLite file (im_inbox + im_participants); those tables leave santi's schema; santi keeps only reply_outbox (producer side). SantiStore holds an ImStore (at <db>.im) and delegates, so ops/service/api call sites are unchanged. Cross-store paths split at the boundary: receipt im_deliveries = santi turn_ids + im deliveries_for_turns; manual reply = santi resolves participant + im enqueues. Auto reply flows reply_outbox -> dispatch -> im.deliver_reply into im's db (at-least-once + idempotent). Per '全部清零', no cross-db migration: im db starts empty, santi's im tables dropped. Obsolete v26 test removed; delivery-failure trigger targets im's db. 0 faults, core 0, 48 test groups green. Remaining purity: ImStore still inside SantiStore (core still crate-deps im); moving to api is the final step. window separate.
im: give the IM delivery layer its own database (shape B)
All checks were successful
guard / guard (pull_request) Successful in 5m21s
326f9febf1
Operator chose shape B: im is a downstream consumer with its OWN database,
not a tenant of santi's. santi-im now exposes an ImStore that opens and owns
its own SQLite file (im_inbox + im_participants, its own schema) rather than
free functions over santi's connection. im's two tables leave santi's schema
entirely; santi keeps only reply_outbox, the producer side.

SantiStore holds an ImStore (opened at "<db>.im") and its im methods delegate
to it, so ops/service/api call sites are unchanged. The two paths that spanned
both stores are split at the store boundary rather than joined in SQL:
- the receipt's im_deliveries: santi reads the receipt's turn_ids from
  receipt_transitions, im returns deliveries for those turn_ids (deliveries_for_turns);
- the manual reply: santi resolves the participant from the strand label
  (im_participant_for_strand stays a santi query), im enqueues the reply.
The automatic reply already flows santi.reply_outbox -> dispatch -> im.deliver_reply,
now crossing into im's db; at-least-once + idempotent (INSERT OR IGNORE on turn_id).

Per the operator's "全部清零" latitude, there is NO cross-db data migration: im's
db starts empty; santi's im tables are simply dropped from the schema (existing
rows are disposable and reset on deploy). The obsolete v26 im-migration test is
removed; the delivery-failure test's trigger now targets im's db. ImDeliveryMode
gains Copy. 0 faults, core debt 0, 48 workspace test groups green.

Remaining toward full purity (noted): the ImStore lives inside SantiStore, so
santi-core still crate-depends on santi-im; moving it to the api composition
root (core im-blind) is the final step. window's own-db split is separate.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
PerishFire deleted branch im-own-database 2026-07-21 08:38:40 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
PerishFire/santi!47
No description provided.