Comfy-Org / Comfy-Org/ComfyUI_frontend

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

Open
#14,738 5 comments 1 reaction 1 assignee Claimed by @huntcsg View on GitHub
Dominant language
TypeScript
Stars
2k
Forks
699
Avg merge
1d 7h
Merged PRs (30d)
490

Description

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

- [x] `team_workspaces_enabled` is at 100 percent for every authenticated Cloud identity
- [x] `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

- [x] Decide between #14530 and the #14612 to #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 https://github.com/Comfy-Org/ComfyUI_frontend/pull/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).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.