fix(seed): GRO-2100 deterministic uat-groomer ↔ UAT Pup Alpha linkage #151
Reference in New Issue
Block a user
Delete Branch "flea/gro-2100-uat-groomer-pet-linkage"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
The UAT seed creates the
uat-groomer@groombook.devBetter Auth account (sign-in works, HTTP 200) but zero appointments link this staffId to any pet, so:GET /api/pets?groomer=mereturns[]GET /api/pets/{anyId}/profile-summaryreturns 404 (no linkage)This is the seed-side counterpart of GRO-1983 (stale password hashes) — that was the credential row, this is the linkage row.
Fix
Add
seedUatGroomerLinkage()inpackages/db/src/seed.ts, called fromseedUatStaffAccounts()so both the fullseed()path andseedKnownUsers()path (prod reset CronJob withSEED_KNOWN_USERS_ONLY=true) produce the deterministic appointment.The function:
uat-groomerstaff record exists (graceful no-op for dev seeds withoutSEED_UAT_STAFF_OIDC_SUB)reset-demo-dataCronJob runs)"Bath & Brush"service id (b0000001-…-0001) with a fallback to any active servicerecentGroomingHistoryreliably includes ita0000001-0000-0000-0000-000000000001as the upsert keyDeterministic contract for GRO-1987
c0000001-0000-0000-0000-000000000002recentGroomingHistory[]/visitCount/upcomingAppointmentc0000001-0000-0000-0000-000000000003If the unlinked case returns 404 instead of 403, that's a separate RBAC defect in the api repo, not the seed.
Verification
After the next 17:00
reset-demo-dataCronJob (UAT) or prod reset (after CTO approval):cc @cpfarhood
Linked
2026.06.02-411c42b(per GRO-2074 evidence)The seed Job `seed-test-data-b5943fb` failed three times on prod with `duplicate key value violates unique constraint "services_pkey"` after migrations 0039/0040 landed. Two interlocking bugs in `packages/db/src/seed.ts` (and the parallel `apps/api/src/db/seed.ts` tree — both kept in sync per the GRO-2052/2013/2014 lesson): 1. The reset `TRUNCATE` excluded `services`, so a prior `seedKnownUsers` run that wrote `id=b0000001-…-004, name="Nail Trim"` survived every reset. The next full `seed()` then tried to insert `id=b0000001-…-004, name="Full Groom — Large"` and PostgreSQL raised `services_pkey` (id collision) — the name-targeted `ON CONFLICT` couldn't fire because the conflict was on a different column. 2. The `demoSvcs` (used by `seedKnownUsers`) had `id=…-004, name="Nail Trim"` while `servicesDef` (used by the full `seed()`) has `id=…-004, name="Full Groom — Large"`. `Nail Trim` was supposed to be `id=…-005` in the demo subset. Fix: * `TRUNCATE services, …` so each reset rebuilds the catalogue from `servicesDef` (CASCADE handles appointments/invoices FKs). * Key both services upserts on `schema.services.id` (not `name`) so deterministic ids always win — defense-in-depth if a future change drops `services` from the TRUNCATE list again. * Reconcile the id↔name map: `demoSvcs[3]` is now `id=…-005, name="Nail Trim"` to match `servicesDef[4]`. * Update `UAT_PLAYBOOK.md §4.5.1` with regression coverage (TC-SEED-1..4). Required for the GRO-2033 close-out: infra PR #605 must repoint to the new image tag (NOT2a6242d) and `apps/overlays/prod/reset-cronjob.yaml` must stay suspended until a one-shot seed Job runs 1/1 against prod. Co-Authored-By: Paperclip <noreply@paperclip.ing>QA review pass. seedUatGroomerLinkage() correctly links uat-groomer to UAT Pup Alpha (c0000001-0000-0000-0000-000000000002) deterministically. UAT Pup Beta left unlinked for TC-UAT-3 (403). Idempotent. GRO-2064 services fix clean. CI Test: passed.