[sbolinger-godaddy]

Problem

CommerceProvider polled GET /api/commerce/config every 5 seconds whenever the last response was unbound or connecting. Failed refreshes kept the last unbound data, so they didn't stop the interval either. In production, every open tab of a site with no store kept polling indefinitely.

Why this approach

A user may select a template that has no store bound. They may never connect a store, or they may connect one minutes, hours or days later. So the goal isn't to wait until a store connects. It's to make sure we never poll indefinitely in production.

To do that, polling ends on a fixed schedule, and a page refresh starts it again. Polling is frequent right after a refresh, when the user is most likely to be connecting a store, then backs off over 30 minutes. A request cap or a more complex backoff was not needed, so the schedule is deliberately simple.

Change

refetchInterval is now timed from when the provider mounts, which is when the page loads:

• 0–5 min: every 5 s
• 5–30 min: every 60 s
• after 30 min: stop

Reloading the page or retryConnection() starts polling again. Focus still refreshes once. These are unchanged: samples, the connecting failure grace, stale data never granting readiness, and no polling in background tabs. Failures don't extend the window.

A page still connecting when polling stops shows the connection error with "Retry connection" instead of "Connecting to the store…" indefinitely. Retrying shows connecting again and starts a new polling period, like a reload. Only a host's readConnectionState() can report connecting, so catalog API outages can't cause this.

A failed retry shows "Connecting to the store…" for at least a second before the error returns. Before, a fast failure re-rendered the same error, so the button looked like it did nothing. Retrying without an error (retryConnection() is public on useCommerce()) only refreshes, so a connected cart or sample cart isn't reset.

A change in the reported state also starts a new polling window. A merchant who leaves an unbound tab open past 30 minutes and connects a store elsewhere gets connecting on the focus refresh, and polling resumes instead of showing "taking too long" right away.

Tests

• Polling backs off after 5 minutes and stops at 30, including after failed refreshes, with no requests over the next day.
• A store connected while backed off (20 minutes in) is picked up.
• A remount after polling stops starts polling again.
• A page still connecting at 30 minutes offers a retry. Retrying shows connecting again, polls every 5 s, stops again at 30 minutes, and a later retry picks up ready.
• A retry that fails shows connecting for a second, then the error. The test fails against the previous code (expected 'error' to be 'connecting').
• Retrying on a connected page keeps the state ready and the cart unchanged. Against the previous commit: expected 'connecting' to be 'ready'.
• unbound past 30 minutes, then a focus refresh finding connecting, polls again and picks up ready. Against the previous commit: expected 'error' to be 'connecting'.

The stopping test fails against the previous refetchInterval (expected 121 to be 66). The other two pass on both versions, as expected. lint, typecheck, build and all 127 package tests pass.

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: c46a3d8

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@godaddy/gd-commerce-storefront	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[wcole1-godaddy]

Reviewed the polling implementation, surrounding connection handling, documentation, and regression tests. No blocking findings. The mount-relative deadline bounds repeated configuration requests even when refreshes fail, without resetting the budget on retry/focus or changing readiness eligibility. The tradeoff that a store connected after the window needs a focus refresh, explicit retry, or remount/reload is intentional and reasonable for this fix.

Validated locally at 4e2d798: package build, all 126 tests, typecheck, and lint pass.

Optional follow-ups: (1) describe timing as relative to provider mount rather than page load, since an SPA can mount/remount it without a reload; (2) strengthen the polling test with an expected request count at the 30-minute boundary (the existing long-idle assertion proves it stops by then, not that it continues until then), plus connecting-state and post-cutoff focus/retry cases. These are non-blocking.