Design: Post-submission business logic errors — 409 conflicts and 422 validation failures mapped to field-level recovery #18

New Issue

2026-09-02T00:08:02Z

Ty commented

2026-09-02 00:08:02 +00:00

Summary

Post-submission business logic errors come back on the Woo response after the user has committed. Two distinct error classes, same recovery screen, different copy and actions.

Error classes

409 Conflict — the only conflict the docs define is duplicate SKU. Recovery: name the conflict and offer the two paths — edit the SKU, or open the existing listing. Never a raw error code.

422 Validation failure — a category or attribute deleted between sync and publish, a price that violates a store rule, or any other value Woo no longer accepts. Recovery: "this value is no longer valid, pick from the current list," mapped back to the specific field.

Design requirements

Every post-submission error maps to the specific field or action it affects — no top-of-screen banners for field-level problems.
409 copy offers the two recovery paths explicitly.
422 copy tells the user the value is stale and surfaces the current valid options from the synced cache.
The draft stays local on the phone so nothing is lost between the error and the fix.
Docs must state both classes and their recovery patterns in CONTENT-WOO and the review-screen UX spec.

Acceptance criteria

409 duplicate SKU surfaces inline on the SKU field with edit-or-open-existing paths
422 stale-value errors surface inline on the affected field with current options
No raw HTTP codes or stack traces reach the user
Draft retained locally across the error-and-retry cycle
CONTENT-WOO and review-screen spec document both error classes and recovery patterns

Linked to docs/refactor-v2. Milestone: POC.

## Summary Post-submission business logic errors come back on the Woo response after the user has committed. Two distinct error classes, same recovery screen, different copy and actions. ## Error classes **409 Conflict** — the only conflict the docs define is duplicate SKU. Recovery: name the conflict and offer the two paths — edit the SKU, or open the existing listing. Never a raw error code. **422 Validation failure** — a category or attribute deleted between sync and publish, a price that violates a store rule, or any other value Woo no longer accepts. Recovery: "this value is no longer valid, pick from the current list," mapped back to the specific field. ## Design requirements - Every post-submission error maps to the specific field or action it affects — no top-of-screen banners for field-level problems. - 409 copy offers the two recovery paths explicitly. - 422 copy tells the user the value is stale and surfaces the current valid options from the synced cache. - The draft stays local on the phone so nothing is lost between the error and the fix. - Docs must state both classes and their recovery patterns in CONTENT-WOO and the review-screen UX spec. ## Acceptance criteria - [ ] 409 duplicate SKU surfaces inline on the SKU field with edit-or-open-existing paths - [ ] 422 stale-value errors surface inline on the affected field with current options - [ ] No raw HTTP codes or stack traces reach the user - [ ] Draft retained locally across the error-and-retry cycle - [ ] CONTENT-WOO and review-screen spec document both error classes and recovery patterns Linked to docs/refactor-v2. Milestone: POC.

Ty added this to the POC milestone 2026-09-02 00:08:02 +00:00

grokbot_ty referenced this issue from a commit

2026-09-02 00:34:50 +00:00

docs: pair locks for #14 #2 #17 #18 (PPM product OK)

Ty referenced this issue

2026-09-03 02:36:57 +00:00

Test plan: POC acceptance test cases for all milestone issues #19

grokbot_ty commented

2026-09-24 16:27:45 +00:00

Verified in main @ 0c00d25:

✅ 409 duplicate SKU: inline recovery with Edit SKU + Open existing product (Publish.svelte lines 92-99)
✅ No raw HTTP codes to user (classify() maps to friendly messages)
✅ Draft retained locally across error-and-retry
⚠️ 422 stale-value: unpublishable path exists (Back to Review) but the specific "value is stale, pick from current list" recovery is not implemented

Moving to post-launch for the 422-stale-value gap.

Verified in main @ 0c00d25: ✅ 409 duplicate SKU: inline recovery with Edit SKU + Open existing product (Publish.svelte lines 92-99) ✅ No raw HTTP codes to user (classify() maps to friendly messages) ✅ Draft retained locally across error-and-retry ⚠️ 422 stale-value: unpublishable path exists (Back to Review) but the specific "value is stale, pick from current list" recovery is not implemented Moving to post-launch for the 422-stale-value gap.

grokbot_ty added the post-launch label 2026-09-24 16:27:45 +00:00

grokbot_ty referenced this issue

2026-09-24 16:33:25 +00:00

POC [06/16]: Duplicate SKU at publish UI — UIE-3 #44

grokbot_ty referenced this issue

2026-09-24 16:33:44 +00:00

POC [07/16]: Stale field recovery at publish UI — UIE-4 #45

Sign in to join this conversation.