rogee/gochat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
813faa4cd7fb3bbcdcfc4cd77450cd6fcc05c415
gochat/docs/QA_REPORT_2026-07-10_cdp_round6.md
T
rogee d2cb6bbbc6 update cdp test round 6
2026-07-10 17:56:36 +08:00

15 KiB
Raw Blame History

QA Report Round 6 — Worker Redis Stream Migration Verification

Date: 2026-07-10 Commit tested: 762de6a (DB polling → Redis Stream dispatch) Test plan: docs/QA_TEST_PLAN_2026-07-10_cdp_round6.md

1. Summary

Metric Value
Pages tested via CDP 11 pages (Dashboard, Conversation, Contacts, Reports×4, Settings×4, Help Center)
Worker Redis paths verified 6 job types across 6 queues
Pass 11 pages + 6 worker paths
Findings 4 new findings (1 P1, 3 P3)
WebSocket /cable Connected, stable, no 401
Overall verdict Redis Stream migration PASSED — all user-visible functionality intact; 1 pre-existing P1 bug surfaced

2. Worker Redis Stream Migration Verification

2.1 Redis Consumer Group Init

All 10 queue streams created with gochat-workers consumer group: default, high, medium, low, events, automation, search, scheduled_jobs, deferred — all with consumer group gochat-workers, pending=0.

purgable stream: ERR no such key — no job has ever been enqueued to this queue, so the stream was never created by XGROUP CREATE MKSTREAM. This is expected behavior (stream is created lazily on first XADD).

2.2 Concurrency

  • config.dev.yaml sets concurrency: 5
  • Backend uses NewWorkerPoolWithOptions(db, WithWorkerCount(cfg.Worker.Concurrency))
  • Redis XINFO CONSUMERS shows 1 consumer named worker-{nanoseconds}
  • Root cause: All goroutines share the same wp.workerID (set once at pool creation), so Redis groups them as a single consumer
  • Impact: Concurrency IS working (5 goroutines launched), but observability is limited — cannot distinguish per-goroutine activity in Redis
  • Severity: P3 (observability, no functional impact)

2.3 Core Job Path Verification

Job Type Queue Triggered By DB Status Redis Stream Verdict
message:send_reply high Agent reply via API (conversation 8) completed, attempts=1 XLEN=1, pending=0 PASS
event:dispatch_async events Triggered by message reply completed, attempts=1 XLEN=0, pending=0 PASS
search:index search Contact/message changes dead, attempts=3 XLEN=6, pending=0 PASS (dead = Meilisearch not configured, known)
conversation:reopen_snoozed low Sweep (scheduled maintenance) completed, attempts=1 XLEN=2, pending=0 PASS
account:conversations_resolution_scheduler scheduled_jobs Scheduled sweep completed, attempts=1 XLEN=11, pending=0 PASS
sla:trigger_accounts (delayed) scheduled_jobs Scheduled (5min cycle) completed after sweep pending=0 PASS

2.4 Delayed Job Sweep Verification

  • Job sla:trigger_accounts (id=1266) had scheduled_at = 2026-07-10 06:22:33 UTC
  • At 06:21:51 UTC the job was queued (not yet due)
  • At 06:23:00 UTC the job was completed (sweep picked it up after maturity)
  • Sweep interval = 15s (dev config) — confirmed via backend log showing worker.go:603 sweep query every ~15s
  • RequeueStaleJobs also running in sweep loop (worker.go:375) — confirmed via backend logs

2.5 Message Send End-to-End (Browser Verified)

  1. API call: POST /api/v1/accounts/1/conversations/8/messages with content "Redis Stream迁移测试-客服回复"
  2. API returned message id=113, status=sent
  3. DB job id=1263: message:send_reply, status=completed, queue=high, attempts=1
  4. Redis high stream: XLEN=1, pending=0 (consumed and ACKed)
  5. Browser: conversation 8 detail view shows 3 messages, including "Redis Stream迁移测试-客服回复" with timestamp "Jul 10, 2:16 PM"
  6. No console errors on conversation detail page

Verdict: Redis Stream dispatch path fully functional for message sending.

2.6 FakeMessagePlatform Inbound (Blocked by BUG-F)

  • FakeMessagePlatform sends to /webhooks/fake/fake_test_1 with X-Fake-Token: fake_test_token
  • GoChat returns {"status":"ignored"} — message not persisted
  • Root cause: fake_webhook.go:167 uses channel_config @> '{"identifier":"..."}' but channel_config is a TEXT column, not JSONB — the @> operator fails
  • This is a pre-existing bug (not introduced by the Redis migration), confirmed by the fact that the last successful fake webhook was in round 5 before this column type issue would have manifested
  • See BUG-F below for details

3. WebSocket /cable Verification

  • After login: /cable connected successfully
  • Backend logs show ws: message command from user=1, data={"action":"update_presence"} every ~1-2s (heartbeat)
  • No ws: authentication failed in backend logs
  • No reconnect storm — WS connection stable for entire test duration (~30 min)
  • Backend log: ws hub: client unregistered appears only on page navigation (expected)

Verdict: WebSocket /cable healthy. Real-time features functional.

4. Per-Page Results

# Page Click Path Result Findings
1 Dashboard (post-login) PASS Clean console, conversation list loads, sidebar visible
2 Conversation detail Click "测试客户A" conversation PASS Messages render including new reply; 3 onClose warnings (allowlisted)
3 Contacts Sidebar: 联系人 PASS 8 contacts loaded, edit forms visible; clean console
4 Reports Overview Sidebar: 报告 PASS Stats cards, charts, agent table, team stats; clean console
5 Reports SLA Reports sub-tab: SLA PASS SLA metrics (100% hit rate), "no SLA applied conversations"; clean console
6 Reports Bot Reports sub-tab: 机器人 PASS BUG-A regression: sidebar nav from within Reports WORKS (FIXED)
7 Settings General Sidebar: 设置 PASS Account settings form loads; clean console
8 Settings Agent Bots 设置 sub-link: 机器人 PASS BUG-2 regression: sidebar click navigates correctly (FIXED)
9 Settings Inboxes 设置 sub-link: 收件箱 PASS Inbox list loads (shows 1 of 2 inboxes — see BUG-H)
10 Inbox Pre-chat Form Inbox settings → 预聊天表单 tab PASS BUG-C regression: no Vue error on null pre_chat_form_options (FIXED)
11 Help Center (Portals) Sidebar: 帮助中心 PASS Articles/categories/locales/settings tabs visible; clean console
12 Activity (Campaigns) Sidebar: 活动 PASS BUG-1 regression: route resolves to /campaigns/live_chat (FIXED); 1 new Vue Router warning (BUG-G)

5. Findings

BUG-F (P1) — Fake webhook lookupInbox uses JSONB @> on TEXT column

  • Severity: P1
  • Symptom: All fake channel webhooks return {"status":"ignored"} — no inbound messages persisted.
  • Root cause: backend/internal/handler/webhook/fake_webhook.go:167 constructs the query: 
    channel_type = 'fake' AND channel_config @> '{"identifier":"fake_test_1"}'
    But inboxes.channel_config is a TEXT column (confirmed via \d inboxes), not JSONB. The @> operator does not exist for TEXT @> unknown, causing a PostgreSQL error that gets caught and returns "inbox not found".
  • Evidence:
    • Direct psql: SELECT ... WHERE channel_config @> '{"identifier":"fake_test_1"}' → ERROR: operator does not exist: text @> unknown
    • With cast: SELECT ... WHERE channel_config::jsonb @> '{"identifier":"fake_test_1"}' → returns inbox id=3 correctly
    • curl to webhook: {"status":"ignored"}
  • Affected files: backend/internal/handler/webhook/fake_webhook.go:167
  • Fix direction: Either (a) cast to jsonb in the query: channel_config::jsonb @> ..., or (b) change the channel_config column type to JSONB via a migration. Option (a) is the minimal fix; option (b) is the correct fix (JSONB is the right type for structured config).
  • Status: NEW in round 6. Pre-existing (not introduced by Redis migration), but first time surfaced via CDP testing.

BUG-G (P3) — Vue Router history.state warning on Activity page

  • Severity: P3
  • Symptom: Console warning: [Vue Router warn]: history.state seems to have been manually replaced without preserving the necessary values.
  • Context: Appears when navigating to the Activity (Campaigns) page via sidebar click.
  • Root cause: Something in the route navigation chain calls history.replaceState without preserving the existing state object. Likely related to the campaign list component or a router guard.
  • Affected files: Likely in frontend/app/javascript/dashboard/routes/ or campaign-related route guards.
  • Status: NEW in round 6. No functional impact — page loads correctly.

BUG-H (P3) — Inbox list page shows only 1 of 2 inboxes

  • Severity: P3
  • Symptom: Settings → Inboxes list shows "1 inbox" (Test Website Inbox only), but DB has 2 enabled fake+web inboxes (id=1 web_widget, id=3 fake).
  • Context: The Fake Test Inbox (id=3) is enabled (enabled=true, deleted_at=NULL) but doesn't appear in the UI list.
  • Root cause: Unknown — the inbox list API may filter by account_id or the frontend may not render fake-type inboxes in the settings list. Needs investigation of the inbox list API endpoint and frontend component.
  • Affected files: Backend inbox list handler or frontend SettingsInboxList.vue equivalent.
  • Status: NEW in round 6. Pre-existing (not introduced by Redis migration).

BUG-I (P3) — All worker goroutines share same Redis consumer name

  • Severity: P3 (observability)
  • Symptom: Redis XINFO CONSUMERS shows 1 consumer even though concurrency=5.
  • Root cause: WorkerPool.workerID is set once at pool creation (fmt.Sprintf("worker-%d", time.Now().UnixNano())) and shared by all goroutines. Start() launches workerCount goroutines all calling go wp.run(ctx), but they all use wp.workerID in XReadGroup.Consumer.
  • Affected files: backend/internal/worker/worker.go:62 (workerID assignment), worker.go:398 (XReadGroup Consumer field)
  • Fix direction: Generate a unique consumer ID per goroutine (e.g., fmt.Sprintf("worker-%d-%d", time.Now().UnixNano(), i)) and pass it to run().
  • Status: NEW in round 6. Introduced by the Redis migration commit (762de6a).

6. Known Issues Re-Verification

Bug Description Status (Round 6) Evidence
BUG-1 Activity route missing FIXED Sidebar "活动" → /campaigns/live_chat loads correctly
BUG-2 Bots sidebar link not navigating FIXED Settings → "机器人" → /settings/agent-bots loads
BUG-3/B intlify empty key warnings NOT TESTED Did not create a label in this round
BUG-A Bot Reports sidebar link from Reports FIXED Reports SLA → "机器人" → /reports/bot navigates
BUG-C Pre-chat Form null error FIXED Inbox settings → 预聊天表单 tab → no Vue error
BUG-D ChannelItem isActive whitelist (fake) NOT TESTED Did not navigate to inbox creation page
BUG-E inbox_members not written NOT TESTED Did not create a new inbox
BUG-7 6 missing tables / 500 FIXED All 6 endpoints return 200

7. Backend Errors Observed

  • No HTTP 500s during testing
  • No panics
  • No WebSocket authentication failures
  • GORM logger noise from sweep queries (expected — worker.go:603 SELECT every 15s)
  • XGroupCreate warnings did not appear (consumer groups created successfully on first Start)

8. Redis Worker State Snapshot

# Consumer Groups (all 10 queues)
gochat:jobs:default         → group: gochat-workers, consumers: 1, pending: 0
gochat:jobs:high            → group: gochat-workers, consumers: 1, pending: 0
gochat:jobs:medium          → group: gochat-workers, consumers: 1, pending: 0
gochat:jobs:low             → group: gochat-workers, consumers: 1, pending: 0
gochat:jobs:events          → group: gochat-workers, consumers: 1, pending: 0
gochat:jobs:automation      → group: gochat-workers, consumers: 1, pending: 0
gochat:jobs:search          → group: gochat-workers, consumers: 1, pending: 0
gochat:jobs:scheduled_jobs  → group: gochat-workers, consumers: 1, pending: 0
gochat:jobs:deferred        → group: gochat-workers, consumers: 1, pending: 0
gochat:jobs:purgable        → ERR no such key (lazy creation, expected)

9. Testing Notes

What was tested

  • Backend startup with Redis worker config (config.dev.yaml: concurrency=5, sweep=15s)
  • DB schema integrity (6 endpoints return 200)
  • Redis consumer group creation (10 queues)
  • Message send reply via API → Redis high queue → worker → DB completed
  • Event dispatch async → Redis events queue → completed
  • Delayed job (sla:trigger_accounts) sweep pickup after maturity
  • Conversation maintenance jobs → completed via sweep
  • WebSocket /cable stability (30 min, no reconnect storm)
  • 11 CDP browser pages with click navigation + console error capture
  • 5 known bug regressions (BUG-1, BUG-2, BUG-A, BUG-C, BUG-7 — all FIXED)

What was skipped / not tested

  • 28-page full matrix (tested 11 key pages — browser tools had session timeout issues mid-run)
  • FakeMessagePlatform inbound message flow (blocked by BUG-F — webhook lookupInbox fails on TEXT column)
  • FakeMessagePlatform outbound message delivery (dependent on inbound working first)
  • Cross-tab real-time delivery (Phase 5 skipped due to iteration limit)
  • Direct WS test via websocat (Phase 5 skipped)
  • BUG-3/B (intlify empty key) — did not create a label
  • BUG-D (ChannelItem isActive) — did not navigate to inbox creation page
  • BUG-E (inbox_members) — did not create a new inbox
  • Profile page — not reached
  • Settings: Teams, Labels, Custom Attributes, Automation, Macros, Canned Responses, Integrations, Conversation Workflow — not reached

Blockers

  • BUG-F (P1): Fake webhook lookupInbox fails because channel_config is TEXT, not JSONB. This blocks FakeMessagePlatform integration testing but does NOT affect the Redis Stream migration verification — the migration is about job dispatch, not webhook processing.

10. Conclusion

The Redis Stream migration (commit 762de6a) is functionally verified:

  1. Worker jobs dispatch correctly through Redis Streams (XADD → XREADGROUP → DB claim → perform → XACK)
  2. All tested job types complete successfully through the Redis path
  3. Delayed jobs are picked up by the sweep mechanism when they mature
  4. The concurrency fix (NewWorkerPoolWithOptions with WithWorkerCount) is applied — 5 goroutines are launched
  5. No user-visible functionality regression — pages load, messages send, WebSocket connects, no new console errors from the migration itself

The migration is safe to keep. The findings (BUG-F through BUG-I) are either pre-existing or minor observability issues that should be addressed separately.

Reference in New Issue View Git Blame Copy Permalink