1 Commits

Author	SHA1	Message	Date
Arnas Donauskas	dc245d5914	feat(flows): foundation for interactive WhatsApp messages (PR 1/4) ... Foundation for the upcoming WhatsApp chatbot flow builder. No runner, no UI yet — just the plumbing that lets the codebase SEND interactive messages (button replies + lists) and RECEIVE the taps as structured message rows. Plan: ~/.claude/plans/understood-research-such-functionality-binary-lake.md ## What's in this PR ### Migration 010_flows.sql - New tables: flows, flow_nodes, flow_runs, flow_run_events - Linchpin partial unique index on flow_runs(user_id, contact_id) WHERE status='active' — at most one active run per contact, makes concurrent webhook deliveries idempotent at the DB layer - Widens messages.content_type CHECK to allow 'interactive' - New messages.interactive_reply_id column for the tapped button/row id - RLS on every table; flow_runs added to supabase_realtime publication - Idempotent throughout — matches the 009_message_actions.sql template ### Interactive Meta senders (src/lib/whatsapp/meta-api.ts) - sendInteractiveButtons: type='interactive', interactive.type='button', up to 3 reply buttons - sendInteractiveList: type='interactive', interactive.type='list', up to 10 rows across sections - Limits exported as INTERACTIVE_LIMITS so flow validation can share the constants - All Meta caps validated BEFORE the network call (button title ≤20 chars, list row title ≤24 chars, ≤10 total rows, no duplicate row ids, body ≤1024 chars, etc.) — misconfigured flows fail at save time instead of as a customer-facing 400 mid-conversation ### Webhook (src/app/api/whatsapp/webhook/route.ts) - Extends WhatsAppMessage interface with `interactive?: { type, button_reply?, list_reply? }` - parseMessageContent returns a new `interactiveReplyId` field; refactored to use a shared `empty` base so every return site picks up the new field without 9 explicit copies - New `case 'interactive'`: uses the tapped option's TITLE as content_text (so the inbox bubble reads "Existing customer", not a UUID) and stashes the id separately - 'interactive' added to ALLOWED_CONTENT_TYPES so the messages insert no longer coerces it to 'text' ### Inbox bubble (src/components/inbox/message-bubble.tsx) - New `case "interactive"` in MessageContent renders the tap with a small "↩ Button reply" affordance so agents reading the inbox can tell at a glance that this was a tap rather than the customer typing the same words ### Types (src/types/index.ts) - ContentType union extended with 'interactive' - Message.interactive_reply_id field ### Engine helpers (src/lib/flows/) - admin-client.ts: thin service-role client wrapper, mirrors automations/admin-client.ts - meta-send.ts: engineSendInteractiveButtons / engineSendInteractiveList — adapts the Meta senders for service-role use, persists messages with sender_type='bot' content_type='interactive', uses the same phone-variant retry as automations/meta-send.ts. Unused in PR #1; ready for the runner in PR #2 ### Tests - 13 new vitest cases in meta-api.test.ts covering Meta's limit validation + payload-shape assertions for both interactive senders ## Validation - npm test → 102/102 (was 89; 13 new) - npm run lint → 0 errors - npm run typecheck → clean - npm run build → clean ## What's NOT in this PR - The runner (dispatchInboundToFlows) — PR #2 - Builder UI / API surface — PR #3 - collect_input / condition / set_tag nodes + templates — PR #4 - react-flow canvas + http_fetch — v2 (PR #5) ## Risks tracked from the plan - messages.content_type CHECK widening: grep'd every consumer; message-bubble.tsx, reply-quote.tsx, send/route.ts, automations/meta-send.ts all handle the new variant correctly (or accept it as a defaulted fallthrough) - engineSendText / engineSendInteractive share ~80% of code; deliberately not pre-factored yet — let both stabilize, extract a shared base in PR #2 once the shape settles Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 13:12:27 +03:00