bf22afb0ed
Additive plumbing for v0.9.0 daemon spec §4.2/§4.4. Adds two nullable
columns to mesh.message_queue — client_message_id (caller-supplied) and
request_fingerprint (canonical sha256 of the send shape) — and threads
them through the broker:
- handleSend reads them off the wire envelope when present
- queueMessage persists them on the row
- drainForMember projects them onto the push so receiving daemons
can dedupe their local inbox by client_message_id
Columns stay nullable so legacy traffic (launch CLI, dashboard chat)
continues to flow uninterrupted. Sprint 7 (broker hardening) will add
the partial unique index and the client_message_dedupe atomic-accept
table once we're ready to enforce dedupe broker-side.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
19 lines
964 B
SQL
19 lines
964 B
SQL
-- Daemon idempotency fields on message_queue (v0.9.0 daemon spec §4.2 / §4.4).
|
|
--
|
|
-- Adds two nullable columns so the daemon can attach its caller-supplied
|
|
-- `client_message_id` and the canonical `request_fingerprint` (sha256 hex
|
|
-- of the canonical request shape) to every send.
|
|
--
|
|
-- Both columns are nullable for backward compatibility — legacy traffic
|
|
-- from `claudemesh launch` and the dashboard chat doesn't carry them yet.
|
|
-- Sprint 7 (full broker hardening) will:
|
|
-- - add a partial unique index `(mesh_id, client_message_id) WHERE
|
|
-- client_message_id IS NOT NULL` once we're ready to enforce dedupe.
|
|
-- - introduce the `mesh.client_message_dedupe` table for atomic accept.
|
|
-- Until then, recording the values lets the broker echo them back on push
|
|
-- so daemon-side inboxes can dedupe correctly even with multiple senders.
|
|
|
|
ALTER TABLE "mesh"."message_queue"
|
|
ADD COLUMN "client_message_id" text,
|
|
ADD COLUMN "request_fingerprint" text;
|