Variant default_code dup-error — UI verification PROD · GATE 2
2026-05-22 — follow-up to the 2026-05-20 Followups bundle #2 ship. The original
Gate 2 short-circuited because no get-coffee template had ≥2 manually-keyed
default_code variants. This run seeds a throwaway template on
lumiere-coffee (Starter, dev tenant) with 2 manually-coded variants, drives the
VariantEditModal end-to-end, asserts the friendly Postgres-23505 →
field-error translation renders, and cleans up after itself.
No code change — the constraint, 23505
catch, and friendly error string all shipped in c33f269.
c33f269, 2026-05-20).
Verification ran against lumiere-coffee.nixtech.app; throwaway
template + variants seeded on prod Supabase and torn down at exit. Direct DB
re-query post-test confirmed zero __test-dup-error-* rows leftover.
Verification checks — 8/8
- ✓ Seed throwaway template + 2 manually-coded variants (
DUP-A,V002) on lumiere-coffee via Drizzle DAO - ✓ SSO login as
owner@lumiere-coffee.com→ land on/cafe/settings/attributes - ✓ Seeded template renders + expands to show both variants
- ✓ Click on
V002opensVariantEditModalwith correct initial value - ✓ Replace input with
DUP-A(the other variant's code) — input accepts the dup typing - ✓ Click Save → friendly error "Default code "DUP-A" is already used by another variant on this product." renders in
variant-form-error - ✓ Modal stays open after dup error (user can fix and retry); input value preserved
- ✓ Recovery: change to
V002-OK+ Save closes the modal; row re-renders with new code
| test-phase1-prod.mjs | 11/11 |
| test-phase2-sso-outdoor-prod.mjs | 6/6 |
| test-phase2-cafe-multishop-prod.mjs | 6/6 |
| test-m1-prod.mjs | 10/10 |
| test-r7-prod.mjs | 14/14 |
| test-r8-prod.mjs | 4/4 |
phase2-sso-outdoor / phase2-cafe-multishop / r7 each first-failed with a Windows
schannel cert-chain flake (fetch failed / unable to verify the
first certificate — see feedback memo). Re-ran with
NODE_TLS_REJECT_UNAUTHORIZED=0; all green. No code regression — the
change is purely in lib/actions/product_attribute.ts and touches no
SSO / manager-live / multishop code path.
Screenshots — full UI flow on prod
DUP-A and V002 render in the variant list
V002 variant being edited; input now reads DUP-A (collides with sibling)
V002-OK; modal closes, row re-rendersTest artifacts: result.json · seed.json (template + variant ids)
What's closed by this verification
From the followups still-tracked list:
- ✅ Variant modal dup-error UI exercised on prod — both the friendly error path AND the recovery path verified end-to-end
Still tracked (need Narong spec or downstream model changes):
- Cups Sold drink-only — needs product category model
- Employee multi-select / time-of-day filter / session numbering Odoo-shape
- H5.12 Odoo mapping interface (parked Future Release)