Channel Adapter E2E Validation Matrix
Last updated 2026-02-12
This matrix records final QA evidence for the adapter-first launch surface:
- custom UI sample app
- Slack starter
- WhatsApp Cloud starter
Matrix
| Channel | Scenario | Status | Evidence |
|---|---|---|---|
| Custom UI | Success | Pass | POST /api/chat returned status=responded with expected response (custom-ui-prod-success) on rooaak-custom-ui-sample-app.fly.dev. |
| Custom UI | Timeout path | Pass | Forced pending message (934dc5dc-83ea-4f88-b34f-60cad060764d) then verified SDK waitForResponse(..., { timeoutMs: 50 }) returns Timeout waiting for message ... response. |
| Custom UI | Duplicate handling | Pass | Two identical requests with same idempotencyKey returned same messageId (5b6f3898-582e-40db-96f3-a152caead5cc). |
| Slack | Success | Pass | Live production smoke in #ai channel: mention received and reply posted back by deployed adapter. |
| Slack | Timeout path | Pass (shared completion contract) | Slack adapter uses Rooaak async completion (pending + webhook). Timeout behavior validated at shared SDK/message lifecycle level (see Custom UI timeout row + SDK timeout error path). |
| Slack | Duplicate handling | Pass (API idempotency contract) | Two /v1/messages sends with same idempotency key + Slack metadata returned same messageId (8b10b274-7df6-48aa-923a-9be9cb7667b6). |
| WhatsApp Cloud | Success | Pass | Live sandbox message received and response delivered back in WhatsApp chat. |
| WhatsApp Cloud | Timeout path | Pass (shared completion contract) | WhatsApp adapter uses Rooaak async completion (pending + webhook). Timeout behavior validated at shared SDK/message lifecycle level (see Custom UI timeout row + SDK timeout error path). |
| WhatsApp Cloud | Duplicate handling | Pass (API idempotency contract) | Two /v1/messages sends with same idempotency key + WhatsApp metadata returned same messageId (c6139a9e-4864-461b-beab-7b5f33839221). |
| Webhooks | Retry queue/backoff | Pass (automated) | src/lib/webhooks/dispatch.test.ts validates retry scheduling, failure classification, and full backoff progression 30s, 2m, 8m, 32m, 2h. |
| Webhooks | Cron processing | Pass (automated) | src/app/api/cron/webhooks/route.test.ts validates authenticated queue processing path. |
| SDK | Async completion paths | Pass (automated) | packages/rooaak-client/src/index.test.ts validates sendAndWait poll and webhook modes plus metadata/idempotency conventions. |
Commands Run
Core test slice:
cd /Users/darian/Documents/Dev/rooaak/rooaak-core npx vitest run src/lib/webhooks/dispatch.test.ts src/app/api/cron/webhooks/route.test.ts packages/rooaak-client/src/index.test.ts
Custom UI production check:
curl -X POST https://rooaak-custom-ui-sample-app.fly.dev/api/chat ...
Timeout-path check (shared SDK lifecycle):
# Force pending by stopping agent then sending message; then:
npx tsx -e "await client.messages.waitForResponse('<pending-message-id>', { timeoutMs: 50, pollIntervalMs: 10 })"Idempotency checks (all three channel metadata types):
curl -X POST https://www.rooaak.com/api/v1/agents/:id/messages \ -H "Idempotency-Key: <same-key>" ...
Notes
- Provider duplicate-event suppression exists in adapter runtime guards and should be validated periodically with provider replay tooling.
- Rooaak public API + SDK flow remains supported alongside adapter deploy patterns.