billingFacadeConsumers rail regression is time-dependent after the boot double-fetch

[christian-byrne]

Residual from the review of #14614. Non-blocking, test reliability.

The rail-selection regression in browser_tests/tests/billingFacadeConsumers.spec.ts is correct as written (the checkout_type and counter-reset fixes both landed), but it is time-dependent in both directions, and the rail-synchronisation change widened the window.

Boot now issues at least two /api/billing/status requests rather than one:

1. billingRailByWorkspaceId starts empty (teamWorkspaceStore.ts, the only writer is setWorkspaceBillingRail), so at boot the rail is undefined and useBillingRouting resolves to workspace
2. the workspace adapter fetches status and writes legacy_stripe
3. type flips to legacy, useBillingContext tears down and rebuilds, and the newly built useSubscription fetches again

bootApp only waits for window.app?.extensionManager, so nothing awaits the settlement of either fetch. Two failure modes follow:

• a late boot fetch can satisfy expect.poll(() => billingRequests.workspaceStatus).toBeGreaterThan(0) on its own, so the test greens without the recovery path running
• the in-flight coalescer can swallow the recovery fetch entirely, so the poll times out and the test flakes red

Suggested: await a settled rail (or a stable request count) before the billingRequests.workspaceStatus = 0 reset, so the poll measures only the recovery fetch.

Thread: #14614 (comment)

[coderabbitai]

🔗 Related PRs

#14242 - fix(billing): support subscription 3DS verification (FE-1436) [merged]
#14268 - fix: retry failed subscription checkout (BE-5054) [open]
#14396 - fix: restart timed-out billing operations [merged]
#14504 - fix(workspace): show subscribe prompt for ended subscriptions [merged]
#14513 - fix(billing): recover past-due plan changes (FE-1251) [merged]

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[christian-byrne]

Moved onto the PR as a review comment so it lands before the flake reaches main: #14614 (review)

Keeping this issue open as the fallback if #14614 merges without it. Close whichever gets resolved first.

[christian-byrne]

Addressed and merged. browser_tests/tests/billingFacadeConsumers.spec.ts on main now waits for the rail to settle before seeding (expect.poll(...).toBeGreaterThan(1) at :170), asserts the legacy balance, then resets the counter at :189 so the poll at :198 measures only the recovery fetch. Landed via #14614.

Residual worth knowing, not worth reopening for: toBeGreaterThan(1) pins the boot double-fetch as required behaviour, so if the redundant second /api/billing/status request is ever collapsed (which would be an improvement) this test fails for a good change. A settled-count or balance-visible wait would tolerate both shapes. Noted on #14645 as part of the billing-routing cleanup.