fix: init blocks when trigger is dropped and created

[strobus]

Summary

• Skip init script DDL when the outbox table already exists, avoiding ACCESS EXCLUSIVE locks that cause cascading freezes during multi-pod autoscaling
• Add 10-second timeout to init() context as a safety net for first-time setup

Problem

NewStore() runs DROP TRIGGER + CREATE TRIGGER DDL on every pod startup. These statements require PostgreSQL ACCESS EXCLUSIVE locks on the outbox table. When a new pod starts during autoscaling:

1. The new pod's init() requests ACCESS EXCLUSIVE on the outbox table
2. Existing pods hold ROW EXCLUSIVE locks from active outbox dispatch transactions
3. The ACCESS EXCLUSIVE request blocks waiting for existing transactions
4. PostgreSQL's lock queue then blocks all subsequent operations on the table
5. Result: cascading freeze across all pods

Fix

init() now checks information_schema.tables first. If the table exists, DDL is skipped entirely. The DDL only runs on first-time setup (when the table doesn't exist yet). A 10-second context timeout is also added so init() can never hang indefinitely.

Test plan

• Existing tests pass (go test ./...)
• Deploy with 1 pod, verify startup completes
• Scale to 3+ pods simultaneously, verify no freeze
• Monitor outbox processing continues during pod scaling

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.