Photon Pally Receive — Recovery Notes

Tracks production-safety notes for the Pally-style receive coordinator used by the Photon/Spectrum bridge.

---

PALLY-1 — Crash/deploy mid-turn recovery

• Status: Mitigated for pre-send turns
• Severity: High if the recovery migration/worker code is absent
• Scope: iMessage and WeChat, because handleInbound is shared

Current Behavior

The bridge now avoids losing accepted inbound messages when a process dies while a turn is in flushing or generating:

• photon_batch_queue and photon_carried_messages rows are marked with

processing_chain_id / processing_started_at when a flush begins.

• Rows are only moved to drained_at / consumed_at after the batch completes,

is intentionally carried forward, or is otherwise terminally retired.

• Active flushes heartbeat photon_in_flight.chain_heartbeat_at; the pally

active gate uses that trigger-immune heartbeat rather than only chain_started_at.

• The queued-flush sweeper also finds stale flushing / generating turns and

starts a fresh pally chain after clearing the old processing marker.

• SIGTERM shutdown waits a bounded grace window for active flushes before

closing the Postgres pool.

This covers the common deploy/restart case where generation was in progress and the sender goes silent after their accepted message.

Residual Caution

Hard crashes during sending are intentionally not recovered by rerunning the LLM turn, because that can duplicate already-delivered bubbles. The existing outbound job recovery path may finish pending sends when it can prove the chain is still deliverable, but ambiguous provider sends should remain visible as failed/stalled work rather than being blindly replayed.