You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] Wishlist reports transient errors as a setup problem #39
setupRequired: true is applied to any error from the Customer Account API, including timeouts and transient network failures. The storefront then tells the merchant their custom.aspen_wishlist metafield is not configured when in fact the definition is fine and the request simply failed. Only genuine schema/permission errors should set this flag.
2. Unreachable code after the retry loop
app/routes/($locale).api.wishlist.ts:165-172
The for (let attempt = 0; attempt < 2; attempt += 1) loop returns on every branch — the only continue is guarded by attempt === 0, so the second iteration always returns. The return wishlistResponse(..., 409) after the loop can never execute.
Either drop it, or restructure the retry so the fallthrough is genuinely reachable (which would be the safer shape if the retry count ever grows beyond 2).
Context
Related to the fix landing in #36, where the API returned productIds: [] on error and wishlist-provider.tsx:89 applied it unconditionally, clearing the customer's wishlist from the UI after a single transient failure.
Worth noting: Pilot has no wishlist feature, so there is no upstream reference implementation to compare against here. This code has no safety net beyond our own review.
Suggested checklist
Distinguish setup/permission errors from transient errors in writeWishlist
Remove or restructure the unreachable branch in the action
Add a unit test covering a transient failure that asserts setupRequired stays false
Acceptance criteria
A timeout against the Customer Account API does not surface a "wishlist not set up" message to merchants
No unreachable branches in app/routes/($locale).api.wishlist.ts
Activity