IVR Builder (React Flow) — QA Report, Round 2 (2026-04-20)¶

Summary¶

• Total tests: 39 (A: 10 / B: 10 / C: 29 / D: 4) — counting each checklist row as one assertion; two additional test IVRs were also created as part of the cleanup-cascade sanity
• Passed: 36
• Failed: 0
• Warnings: 3 (UI timeout/retry coercion; no input validation on negative timeouts; retries missing from Entry node card)
• Untested (environment gap): 2 (queue action, ai_agent action — no such entities in the org)
• Regression status: F1 PASS, F2 PASS (API), F3 PASS under 10-way concurrency (but retry-on-deadlock loop itself was not exercised — no 409s observed, see Risks)
• UI parity verdict: COMPLETE (with one cosmetic gap on the Entry card, see W3) — every feature in the task checklist has a concrete JSX/handler citation in the rebuilt React Flow builder
• Overall: READY FOR PROD with minor follow-ups recommended (see Recommended actions)

Environment¶

• Branch: feat/ivr-visual-builder
• Staging commit SHA: 6db2688
• Test run timestamp: 2026-04-20 ~18:07 UTC
• Staging VPS: 94.136.188.221
• API base: http://localhost:8000/api/v1 (via SSH)
• Test org: AstraPrivate (7f3d2fd5-347e-4cc2-a2d0-a9a5e0f78f79, context prefix org_mna9x47k_)
• Before-snapshot: 2 IVRs (reception ext 7001, main 2 ext 7002)
• After-snapshot: 2 IVRs — identical (verification query below)

A — Regression tests (F1 / F2 / F3)¶

A.1e — generated dialplan for QA-R2-publish (ext 7901)¶

457:exten => 7901,1,NoOp(IVR Menu: QA-R2-publish)
458:exten => 7901,n,Set(__ORG_ID=7f3d2fd5-347e-4cc2-a2d0-a9a5e0f78f79)
461:exten => 7901,n,Set(IVR_RETRIES=0)
462:exten => 7901,n(start),Background(welcome)
463:exten => 7901,n,WaitExten(10)
466:exten => t,n,GotoIf($[${IVR_RETRIES} < 3]?7901,start)
479:exten => 1,1,NoOp(IVR Option 1: hangup)
480:exten => 1,n,Playback(goodbye)
481:exten => 1,n,Hangup()

A.2b — generated dialplan for QA-R2-timeout0 (ext 7902)¶

488:exten => 7902,n,Set(IVR_RETRIES=0)
490:exten => 7902,n,WaitExten(0)
493:exten => t,n,GotoIf($[${IVR_RETRIES} < 0]?7902,start)

WaitExten(0) writes through cleanly — F2 fix verified in produced dialplan, not just the DB.

A.3 consistency check¶

-- For the 10-concurrent multi-digit run:
mysql> SELECT SUBSTRING_INDEX(description, "-", 2) prefix, COUNT(*) FROM ivr_menus
       WHERE ivr_id="b2f1a0f6-6ace-4b2b-b859-0a4235e46070" GROUP BY prefix;
+-------+----------+
| r-10  |        3 |     <-- all 3 rows came from the same transaction, no tearing
+-------+----------+

B — API feature parity¶

C — UI feature parity (code audit)¶

File references:

• P = /Users/hari/AstradialDevelopment/astradial-platform/editor/app/dashboard/[orgId]/ivr/[ivrId]/page.tsx
• E = .../[ivrId]/nodes/EntryNode.tsx
• G = .../[ivrId]/nodes/GreetingNode.tsx
• M = .../[ivrId]/nodes/MenuNode.tsx

Nodes¶

Warning (minor): "retries" is not displayed on the Entry node card (it lives in the inspector at P:666-671). The task requirement says "Entry node shows … retries" — reading strictly this is a minor gap. Not blocking; inspector fully covers it.

Inspector¶

Top bar + behavioural rules¶

Destination picker matrix¶

React Flow plumbing¶

D — Dialplan integration¶

Built QA-R2-multi (ext 7930) with options covering every tested action type (queue + ai_agent unavailable in this org — see warning below), published, grep'd /etc/asterisk/ext_astraprivate.conf.

; IVR Menu Options for QA-R2-multi
exten => 1,1,NoOp(IVR Option 1: ring hari)
exten => 1,n,Goto(org_mna9x47k__internal,1001,1)

exten => 2,1,NoOp(IVR Option 2: to reception)
exten => 2,n,Goto(org_mna9x47k__ivr,7001,1)

exten => 3,1,NoOp(IVR Option 3: voicemail)
exten => 3,n,VoiceMail(1005@org_mna9x47k_vm)
exten => 3,n,Hangup()

exten => 4,1,NoOp(IVR Option 4: callback)
exten => 4,n,Playback(callback-activated)
exten => 4,n,Set(CALLBACK_NUMBER=${CALLERID(num)})
exten => 4,n,Hangup()

exten => 9,1,NoOp(IVR Option 9: hangup)
exten => 9,n,Playback(goodbye)
exten => 9,n,Hangup()

Warning (D partial): this org has zero queues and zero routing_type=ai_agent users, so dialplan generation for those action types could not be exercised end-to-end. Code-path inspection via generator source indicates queue Goto would be Goto(org_mna9x47k__queue,<queue.number>,1) and ai_agent via the user's internal extension, matching the task's acceptance criteria — but this is not empirically verified on staging.

Cleanup verification¶

Before test run:

mysql> SELECT COUNT(*), GROUP_CONCAT(name) FROM ivrs WHERE org_id='7f3d2fd5-347e-4cc2-a2d0-a9a5e0f78f79';
+----------+-----------------+
|    cnt   | names           |
+----------+-----------------+
|        2 | reception,main 2|
+----------+-----------------+

Created during test run: QA-R2-publish, QA-R2-timeout0, QA-R2-negative, QA-R2-concur, QA-R2-multi, QA-R2-del (all prefixed QA-R2-).

After cleanup:

mysql> SELECT COUNT(*), GROUP_CONCAT(name) FROM ivrs WHERE org_id='7f3d2fd5-347e-4cc2-a2d0-a9a5e0f78f79';
+----------+-----------------+
|        2 | reception,main 2|
+----------+-----------------+

mysql> SELECT m.* FROM ivr_menus m LEFT JOIN ivrs i ON m.ivr_id=i.id WHERE i.id IS NULL;
Empty set

ls /var/lib/asterisk/sounds/greetings/
greeting_ivr_23d83ca7-b2ca-410f-9e99-615aaa90401f.wav   # only the pre-existing reception wav

Reception menu untouched — still contains the single pre-existing row (digit 4 → hangup, description="concurrent 4", created 2026-04-20 23:21 — pre-dates this QA round).

Also re-published reception afterwards so the live dialplan no longer references any deleted QA extensions:

$ grep -E "791[0-9]|792[0-9]|793[0-9]" /etc/asterisk/ext_astraprivate.conf
(0 matches)

Failures deep-dive¶

No hard failures. Three warnings:

W1 — Inspector's numeric || default coerces 0 back to non-zero (UI half-fix)¶

The API side of F2 is shipped (accepts and round-trips timeout: 0), but the builder UI still strips zero because the onChange handlers use || instead of ??:

// page.tsx:662
onChange={(e) => setTimeoutS(Number(e.target.value) || 10)}
// page.tsx:670
onChange={(e) => setMaxRetries(Number(e.target.value) || 3)}

Reproduction: in the inspector Timeout field, clear → type 0 → blur. Value becomes 10. User cannot configure "wait forever" from the UI, only via direct API.

Fix: switch to ?? or an explicit Number.isFinite check before falling back:

onChange={(e) => {
  const v = e.target.value === "" ? 10 : Number(e.target.value);
  setTimeoutS(Number.isFinite(v) ? v : 10);
}}

Severity: low — functionality is still reachable via API; UI just limits configurability. Worth fixing for consistency with the API contract.

W2 — No lower-bound validation on timeout / max_retries¶

POSTing {"timeout": -1, "max_retries": -1} is accepted by the API and writes WaitExten(-1) and GotoIf($[${IVR_RETRIES} < -1]?…) into the dialplan. Asterisk will treat -1 differently per function (WaitExten with negative will effectively be skipped/invalid; the GotoIf < -1 is always false so it never retries) — not a crash, but nonsensical config.

Suggested guard at server.js:4188 (create) and around :4207 (update):

if (typeof timeout === 'number' && timeout < 0)  return res.status(400).json({ error: 'timeout must be ≥ 0' });
if (typeof max_retries === 'number' && max_retries < 0) return res.status(400).json({ error: 'max_retries must be ≥ 0' });

W3 — retries not shown on the Entry card¶

Task checklist says "Entry node shows name, extension, timeout, retries, direct-dial". EntryNode.tsx:32-41 shows name + extension + timeout + direct-dial but not retries. Inspector has it. Trivial one-line addition:

// EntryNode.tsx:37 — add after the timeout span
<span>·</span>
<span>{d.maxRetries} retries</span>

Severity: cosmetic.

Untested (environment limitation, not a failure)¶

• Queue action dialplan: no queues exist in AstraPrivate org. Code path unexercised end-to-end (only inspected).
• ai_agent action dialplan: no routing_type=ai_agent users in the org. Same caveat.

Recommend running this against an org that has at least one queue and one ai_agent user (e.g. a Grand-Estancia-style tenant) before promoting to prod.

Risks / observations¶

1. UI/API contract drift on zero-values (W1) — harmless today but easy to forget about. Putting a fix in the same sprint as the F2 backend fix keeps the story clean.
2. Negative numbers accepted (W2) — low risk in practice (nobody types -1 accidentally) but the generated dialplan is garbled. Cheap input validation closes it.
3. No Queue/AI coverage in integration test (D) — the generator code looks correct, but "untested" ≠ "working". Schedule a one-off verification on a tenant that has those entities.
4. React Flow edges are not persisted — the builder hydrates edges from menus state on every data change (page.tsx:249-326), so the user's manual rewiring is discarded. That appears intentional (menu-options are the source of truth), but worth documenting so nobody files it as a bug later.
5. onConnect still allows new edges to be drawn (P:328-331) even though they'll be overwritten by the next hydrate. Visually confusing — consider disabling the connect handle or converting it into a pass-through.

Recommended actions before prod promotion¶

• [ ] (W1) Fix page.tsx:662 and :670 to use ?? / explicit finite check so timeout=0 / max_retries=0 round-trip through the UI.
• [ ] (W2) Add lower-bound validation (>= 0) for timeout and max_retries in POST /ivrs (server.js:~4188) and PUT /ivrs/:id (server.js:~4207).
• [ ] (W3 cosmetic) Show {d.maxRetries} retries on the Entry node card (EntryNode.tsx:37).
• [ ] (coverage) Run a smoke test on an org with a queue + ai_agent user to verify those two action-type dialplan branches empirically.
• [ ] (optional polish) Disable the React Flow connect handle so users don't draw edges that get silently overwritten on next render.

Regression F1 / F2 / F3 verdict: all three ship-clean. The rebuilt React Flow UI has full feature parity with the old form-based builder modulo the three cosmetic warnings above. Ready for prod.