Confirm 100% rollout of both retired Cloud flags and repoint cloud#6040 before the FE stack merges

[christian-byrne]

Blocking gate for the frontend rollout-retirement stack #14612, #14613, #14614, #14615.

Two confirmations are needed from the Cloud side before that stack is safe to merge and before the backend can drop the keys. Neither is a code change and neither can be answered from the frontend repo.

1. Confirm the rollout is actually complete

• team_workspaces_enabled is at 100 percent for every authenticated Cloud identity
• consolidated_billing_enabled is at 100 percent for every authenticated Cloud identity

common/featuregates/flags.go carries the BE-119 governance rule forbidding removal of a flag from AllFlags/FrontendFlags without independently confirming no current frontend release still reads it. That rule exists because cloud#3171 removed frontend-consumed flags prematurely and had to be reverted by #3227 and #3228.

After #14613 merges, isCloud (a compile-time constant) replaces the flag read, so any cohort the backend still gates would land on the workspace-init error panel with no way into the app. There is no longer a server-side lever to undo that; recovery requires a frontend rollback.

2. Resolve the two competing frontend implementations

• Decide between feat: retire team workspace rollout flags #14530 and the fix(workspace): recover from initialization failures #14612 to refactor(billing): retire consolidated billing rollout flag #14615 stack, and close the loser
• Repoint the rollout dependency in Comfy-Org/cloud#6040 to whichever one ships

Comfy-Org/cloud#6040 currently reads: "do not merge/deploy this PR until #14530 is deployed." #14530 is CONFLICTING/DIRTY and was last updated 2026-08-02. If the dante stack is the one that ships, that line is pointing at a PR that will never deploy.

3. Deployment ordering is a drain requirement, not just an ordering

Worth writing into the deploy plan. refreshRemoteConfig.ts coerces an absent key to a persisted false, so a browser tab left open across the backend key removal downgrades its own live session. Deploying the frontend first is necessary but not sufficient; old frontend versions and open tabs have to age out before the keys are removed.

Related: #14645 (routing consolidation follow-up).

[coderabbitai]

🔗 Related PRs

#14614 - refactor(billing): use canonical status and preserve legacy rail [merged]
#15046 - feat(billing): flag legacy billing migration [merged]
#15051 - feat(workspace): expose workspace switcher on desktop/local for credit selection [open]
#15106 - refactor(billing): consolidate billing_rail classification into one policy site [open]
#15164 - feat(workspace): enable local credit workspace switching [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 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]

Rollout confirmed. I verified offline that both team_workspaces_enabled and consolidated_billing_enabled are at 100 percent for every authenticated Cloud identity.

Recording the provenance explicitly since it was out of band rather than in this thread: this is a human confirmation, not something derived from the repo, and it is what the BE-119 rule in common/featuregates/flags.go asks for before a key is removed from AllFlags/FrontendFlags.

What that settles: the lockout risk is gone. Replacing the flag read with the compile-time isCloud no longer strands a gated cohort, because there is no gated cohort. That was the blocking half of my question on #14613 and the reason it was marked blocking.

What it does not settle, and what is still open on this issue:

• team_workspaces_enabled at 100 percent
• consolidated_billing_enabled at 100 percent
• Decide between feat: retire team workspace rollout flags #14530 and the fix(workspace): recover from initialization failures #14612 to refactor(billing): retire consolidated billing rollout flag #14615 stack, and close the loser
• Repoint the rollout dependency in https://github.com/Comfy-Org/cloud/pull/6040 away from feat: retire team workspace rollout flags #14530

The two remaining items are backend sequencing and duplicate-effort cleanup. Neither blocks merging the frontend stack now that rollout is confirmed; both block deploying the backend key removal.

Still worth carrying into the backend deploy plan: the ordering is a drain requirement, not just an ordering. refreshRemoteConfig.ts coerces an absent key to a persisted false, so old frontend versions and open tabs have to age out before the keys are removed, not merely be superseded by a newer build.

@huntcsg the remaining two are yours.

[christian-byrne]

@huntcsg status update, and the ask is unchanged.

The entire frontend stack has now merged: #14612, #14613, #14614 and #14615 are all on main. Both retired keys are gone from the frontend: zero references to team_workspaces_enabled or consolidated_billing_enabled across src/ and browser_tests/.

Rollout is confirmed. Christian verified offline that both flags are at 100 percent for every authenticated Cloud identity, which is the BE-119 confirmation this issue was waiting on. That box is ticked.

• team_workspaces_enabled at 100 percent
• consolidated_billing_enabled at 100 percent
• Decide between feat: retire team workspace rollout flags #14530 and the merged stack, and close the loser
• Repoint the rollout dependency in https://github.com/Comfy-Org/cloud/pull/6040

The remaining two are yours and are now the only thing between here and the backend key removal. #14530 is still open, still conflicting, and has not moved since 2026-08-02; its change is now redundant with what is on main, so it should almost certainly just be closed. https://github.com/Comfy-Org/cloud/pull/6040 still reads "do not merge/deploy this PR until ComfyUI_frontend#14530 is deployed", which is now pointing at a PR that will never deploy.

Restating the deploy precondition because it is easy to read as a simple ordering: it is a drain requirement. refreshRemoteConfig.ts coerces an absent key to a persisted false, so a browser tab left open across the backend key removal downgrades its own live session. Old frontend versions and open tabs need to age out first, not merely be superseded by a newer build.

[christian-byrne]

Tracked in Linear under Billing — Subscription & Account Lifecycle: https://linear.app/comfyorg/issue/BE-7700

Filed so this sits in the assignee's normal queue rather than only on GitHub. GitHub stays authoritative for code state; the Linear ticket carries ownership and priority.

[christian-byrne]

Status update, 2026-08-16.

Ticked the first three boxes: rollout was confirmed at 100 percent for both flags, and #14530 was closed on 2026-08-16, which settles the decide-and-close-the-loser item. The stack (#14612, #14613, #14614, #14615) is what shipped.

One box left, and closing #14530 made it more urgent rather than less. https://github.com/Comfy-Org/cloud/pull/6040 still reads:

Rollout dependency: do not merge/deploy this PR until #14530 is deployed.

That now names a closed PR, so the stated precondition can never be satisfied as written. It needs repointing at the merged stack before the backend key removal can be scheduled. Tracked as https://linear.app/comfyorg/issue/BE-7700.

Restating the precondition it should carry: deploying the frontend is necessary but not sufficient. refreshRemoteConfig.ts coerces an absent key to a persisted false, so a tab open across the key removal downgrades its own live session. Old frontend versions and open tabs have to age out. Drain, not ordering.