Inbound idempotency: redelivered events create duplicate tickets, so a conversation can get more than one AI answer

[NathanTarbert]

Outpost is meant to answer exactly one message per ticket. That invariant is enforced
per ticket (see the guard in packages/outpost/queue/src/handlers/ai-response.ts), so
it holds only as long as one conversation maps to one ticket. None of the four inbound
doors guarantee that: every one of them will happily create a second ticket for a
message it has already seen, and the second ticket gets its own AI answer. From the
reporter's side that is indistinguishable from the bot answering twice.

Found by the review round on the one-response-per-ticket change; deferred because the
fix needs a schema migration and touches all four doors, which is a different blast
radius than that change had.

Sites

• packages/outpost/shared/src/platforms/inbound.ts:158 — handleNewTicket does no
  find-first on (source, sourceId), and there is no unique constraint backing it
  (schema.prisma has an index only). A redelivered thread-start creates a second
  ticket and a second answer.
• apps/web/src/app/api/webhooks/postmark/route.ts:102 — no MessageID idempotency.
  Postmark retries on any non-2xx, and the handler returns 500 if createJob throws
  after ticket.create succeeds, so the retry duplicates both.
• apps/github-app/src/webhooks/issue-comment.ts:53 — no comment.id idempotency;
  redelivery duplicates messages.
• apps/slack-bot/src/events/message.ts:41 — no thread-start dedupe.
• apps/discord-bot/src/events/thread-create.ts:75 — a duplicate ThreadCreate
  duplicates ticket and answer.

Also fixed by the same constraint

packages/outpost/queue/src/handlers/ai-response.ts:97 — the one-response guard is
check-then-write. AI_RESPONSE runs at concurrency 4 (apps/worker/src/index.ts:63),
so two jobs for the same ticket can both read "no BOT row yet" and both answer. A
transaction around the check does not close this across connections; a uniqueness
constraint does. That is why it belongs here rather than in the guard's own PR.

Suggested shape

1. Migration: unique on Ticket(source, sourceId) where sourceId is non-null, plus
   whatever partial-unique expresses "at most one AI-generated BOT message per ticket".
2. Make each door idempotent on its natural platform key — MessageID, comment.id,
   Slack event id, Discord thread id — rather than re-deriving dedup per door.
3. Have handleNewTicket upsert-or-return on (source, sourceId) so the shared handler
   is safe by construction and the bots inherit it.

Needs tests per door for the redelivery case; none exist today.

[NathanTarbert]

Rescoping after reading the diffs on #170 — two of the six bullets landed there, so this issue is narrower than filed.

Closed by #170

The per-ticket claim race. Fully fixed, and by the mechanism this issue proposed. Message gained a nullable responseKey, a unique index on (ticketId, responseKey), and a MessageResponseState enum (PENDING/DELIVERED/ESCALATED). The handler elects exactly one PRIMARY_AI_RESPONSE per ticket at the database boundary, so concurrent jobs can no longer both pass a check-then-write; the loser catches a narrowly-identified P2002 and stops. State transitions are compare-and-set via updateMany guarded on responseKey + responseState, not blind update by id. The column is nullable specifically so historical BOT rows stay valid and still count as proof a ticket was answered.

Postmark MessageID idempotency. Closed. Ticket_email_sourceId_key is a partial unique index on Ticket(sourceId) WHERE source = 'EMAIL' AND sourceId IS NOT NULL, plus idempotent creation in the route, so a Postmark retry cannot mint a second ticket.

Still open

The remaining doors have no dedupe on their natural platform key, so a redelivered event still creates a second ticket — which gets its own AI answer, because the one-response guard is per ticket:

• No generic (source, sourceId) uniqueness. Only EMAIL got an index. Discord, Slack, Teams, and both GitHub sources are unconstrained.
• handleNewTicket has no find-first-or-upsert on (source, sourceId). The P2002 handling in inbound.ts covers the User.email race only, not ticket creation.
• GitHub comment.id — no idempotency; redelivery duplicates messages.
• Slack thread-start — no dedupe. The findFirst in events/message.ts is the untracked-reply pre-filter, gated behind if (!message.isThreadStart), so it never runs for a thread start.
• Discord ThreadCreate — no dedupe; a duplicate event duplicates ticket and answer.

Suggested shape for what's left

Follow the pattern #170 established rather than inventing a second one: constrain at the database boundary, then make the writer tolerate the collision.

1. Partial unique index on Ticket(source, sourceId) WHERE sourceId IS NOT NULL, so every platform gets what EMAIL now has. Worth checking for existing duplicate rows first — this index will fail to build if any exist.
2. handleNewTicket returns the existing ticket on collision instead of throwing, so all four bots inherit safety from the shared handler rather than each re-deriving it.
3. Per-door keys where the platform gives one (comment.id, Slack event id, Discord thread id).

Still no redelivery tests on any door.

[NathanTarbert]

One of the five doors is closed; recording which, so the remaining scope is clear.

Closed: the Postmark webhook is idempotent on redelivery (apps/web/src/app/api/webhooks/postmark/route.ts:235-249, :360-419), and the check-then-write race on the AI response is settled by the database rather than by application logic — Message now carries @@unique([ticketId, responseKey]) and @@unique([ticketId, sourceMessageId]).

Still open, and these are the four this issue now tracks:

• Ticket has only @@index([source, sourceId]), not a unique constraint, so nothing at the database level stops a second ticket for the same source event
• handleNewTicket is a bare prisma.ticket.create with no find-first (packages/outpost/shared/src/platforms/inbound.ts:230-240)
• apps/github-app/src/webhooks/issue-comment.ts:52-59 does not dedupe on comment.id
• neither apps/slack-bot/src/events/message.ts:35 nor apps/discord-bot/src/events/thread-create.ts:70-82 dedupes a redelivered thread-start

A redelivery on any of those four still produces a duplicate ticket, which is the failure the issue was filed for. The email path is simply no longer one of them.