## Problem
On the Comfy Cloud login flow, the OAuth / MCP consent modal
(`/cloud/oauth/consent`) renders with broken colors: a light-gray card
on the dark onboarding background, with a washed-out, barely-legible
title, section headers, and permission labels. Reported via internal QA.
## Root cause
The cloud onboarding shell (`CloudTemplate`) paints a dark surface using
hardcoded brand tokens (`primary-comfy-ink` / `primary-comfy-canvas`)
but never applies `.dark-theme` to the DOM. That class — which flips the
design-system **semantic** tokens to their dark values — is only set by
`GraphView` / `BaseViewTemplate`, neither of which mounts on the cloud
onboarding routes.
`OAuthConsentView` is the first onboarding view whose primary surface
(the card) is built on semantic tokens, so without a dark-theme context
they fall back to their light values:
| token | fell back to (light) | should be (dark) |
| --- | --- | --- |
| `secondary-background` (card) | `#e9e9e9` | `#262729` |
| inherited foreground (title / headers / labels) |
`primary-comfy-canvas` `#c2bfb9` on `#e9e9e9` → illegible | `#c2bfb9` on
`#262729` → legible |
| `muted` (subtitle / help / card border) | `#71717a` | `#a1a1aa` |
| `primary-background` (scope checks + CTA) | azure-400 `#31b9f4` |
azure-600 `#0b8ce9` |
The card sets no foreground of its own, so its title/headers/labels
inherit `primary-comfy-canvas` from the shell — fine on a dark card,
illegible on the light fallback one. The component markup is already
correct; it just never receives a dark-theme context. (The sibling
login/signup pages avoid this because they use hardcoded `primary-comfy`
/ `brand-yellow` tokens, not semantic ones.)
## Fix
Scope `.dark-theme` to the consent view's own root `<main>` — the same
class mechanism `BaseViewTemplate` uses for its `dark` prop. The card's
semantic tokens now resolve dark and the text is legible, while the
sibling login / signup / survey screens are untouched.
This is intentionally scoped to the reported view. Theming the whole
cloud onboarding shell (so any future semantic-token component there is
covered automatically) is a reasonable follow-up, but it shifts several
other views and has a wider blast radius, so it's left out of this fix.
## Preview (real component)
CI auto-deploys a Storybook preview of this branch to Cloudflare Pages
(see the **🎨 Storybook** comment below). The `Cloud/OAuth/Consent` story
renders the populated card with no backend — and with this change it
themes dark correctly:
**▶ [Cloud/OAuth/Consent — live
story](https://fbae9a69.comfy-storybook.pages.dev/?path=/story/cloud-oauth-consent--single-workspace)**
And the fix on the **live app**, captured in a preview environment via a
real OAuth flow:
## Verification
The `Cloud/OAuth/Consent` Storybook story renders the real component;
switching the Storybook theme global from **light → dark** reproduces
this exact before/after. This change makes the live route match the dark
rendering. Existing `OAuthConsentView.test.ts` assertions are on
text/roles and are unaffected by the added class.
## ELI-5
The "allow access?" popup was wearing light-colored clothes inside a
dark room, so the words blended into the card and you couldn't read
them. This tells the popup it's in a dark room, so it dresses for the
dark and the text shows up again. Nothing else in the room changes.
## Summary
Preview3DAdvanced is a Preview3D variant that emits live viewport state
as outputs (model_file, camera_info, model_3d_info, width, height) plus
a width/height pair. Reuses the LOAD_3D capture widget for the viewport
but
skips upload/clear buttons (it has no model_file widget).
Adds a camera-only + gizmo serializeValue path (no scene/mask/normal
image uploads since no image outputs are emitted) and an onExecuted that
loads the saved preview model via
Load3DConfiguration.configureForSaveMesh and applies the input
camera_info forwarded via PreviewUI3D when one was connected, so a chain
of Preview3DAdvanced nodes propagates camera state in a single run
instead of lagging one hop per execution.
Drops the per-node camera lock toggle (retainViewOnReload) across all 3D
nodes (Load3D, Preview3D, Preview3DAdvanced).
The viewport now always preserves the user's adjusted framing after the
first model load; the toggle was rarely needed and made chained
propagation ambiguous. Saved workflows with retainViewOnReload in their
cameraConfig continue
to load, the field is simply ignored at runtime.
camera_info / model_3d_info resolved by execute: the input when
connected, otherwise the viewport's own live state. Applying them
overrides the preserved viewport in the input case and is a no-op echo
when the viewport already matches. Only the first model_3d_info entry is
applied, single-object viewer currently.
BE: https://github.com/Comfy-Org/ComfyUI/pull/14175
## Screenshots (if applicable)
https://github.com/user-attachments/assets/42536469-e188-492a-9864-cdb6bfa76e97
## Summary
<img width="1600" height="882" alt="fe-mask-icon-after"
src="https://github.com/user-attachments/assets/7ddd6ae3-4c6a-4c4d-9a61-2059851bd4f9"
/>
Stacked on #12563 (FE-839). Follow-up requested in the FE-839 thread by
@AlexisRolland and @alextov: the media-node context menu gives every
image action an icon **except** `Open in Mask Editor`, leaving its label
misaligned with the rest of the group.
This reuses the existing custom `comfy--mask` icon — the same one shown
on the node image overlay / selection-toolbox `MaskEditorButton` — for
the `Open in Mask Editor` entry. With it, all five image actions (`Open
Image`, `Open in Mask Editor`, `Copy Image`, `Paste Image`, `Save
Image`) now carry an icon and their labels line up.
- Follow-up to FE-839
- Context (FE-839 Slack thread): Alexis — *"it would be nice to have an
icon for open in mask editor. There is one on the image overlay in the
node which could be reused"*; Alex Tov — icon name is `mask`, a custom
icon.
> The broader idea of reserving a placeholder/buffer for options that
have no icon so **all** menu labels align (Alex Tov) is intentionally
out of scope here — this PR only completes the image-action group.
## Implementation
- `useImageMenuOptions.ts`: add `icon: 'icon-[comfy--mask]'` to the
`Open in Mask Editor` option.
No rendering changes are needed — `NodeContextMenu.vue` already renders
the icon via `<i v-if="item.icon" :class="[item.icon, 'size-4']" />`,
and `comfy--mask` is already registered (custom collection loaded from
`packages/design-system/src/icons`, used today by `MaskEditorButton.vue`
and `linearMode/DropZone.vue`).
## Red-Green Verification (local)
| Step | Result |
|------|--------|
| Test-only commit (`d8b7e2c`) | 🔴 Red — `expected undefined to be
'icon-[comfy--mask]'`; image group not fully iconed |
| Fix commit (`feeb505`) | 🟢 Green — 10/10 passing |
## Before / After
Right-click a media node (Load / Preview / Save Image) → image-action
group at the top of the menu:
| Before (base `FE-839`) | After (this PR) |
| --- | --- |
| `Open in Mask Editor` has no icon — its label sits flush-left while
the other four image actions are indented past their icons. | `Open in
Mask Editor` shows the mask icon; all five image actions line up. |
<!-- drag fe-mask-icon-before.png and fe-mask-icon-after.png into the
two cells above -->
Captured locally against a Load Image node with `example.png` (Vue nodes
enabled), dev server proxied to a live backend.
https://comfy-organization.slack.com/archives/C0A7ADM4797/p1780467176353799?thread_ts=1779462362.995709&cid=C0A7ADM4797
## Test Plan
- [x] Local red on the test-only commit
- [x] Local green on the fix commit
- [x] `useImageMenuOptions.test.ts` — 2 new tests (mask icon present on
`Open in Mask Editor`; every image action carries an icon)
- [x] eslint clean on changed files
- [ ] Manual: right-click a media node and confirm the mask icon renders
next to `Open in Mask Editor`
## Summary
The assets API exposes an asset's content hash as `hash`. An older
`asset_hash` field was a deprecated alias carrying the same value. This
PR moves the frontend fully onto `hash` and removes `asset_hash` from
the frontend entirely.
## Changes
- Read `asset.hash` (no `?? asset_hash` fallback) across the asset
consumers:
- `useMediaAssetActions` — widget-value variants + cloud-mode
stored-filename resolution
- `assetsStore` — input-asset-by-filename map
- `assetMetadataUtils.getAssetUrlFilename`
- `missingMedia` resolver/scan and `missingModel` scan hash matching
- `useComboWidget` / `useWidgetSelectItems`
- `assetPreviewUtil.findOutputAsset` now queries `/assets?hash=` instead
of the deprecated `?asset_hash=` param and matches on `a.hash`.
- Removed `asset_hash` from the zod asset schema and the local
`AssetRecord` type. Responses that still include the alias parse cleanly
— zod strips unknown keys — so the declared field protected nothing once
the reads were gone.
- Purged `asset_hash` from all test fixtures/mocks; tests key on the
canonical `hash`.
## Safety / rollout
The API currently emits **both** `hash` and `asset_hash` with identical
values, so reading `hash` is safe today. This is the frontend half of
retiring the alias; the backend stops emitting `asset_hash` only after
this ships and old bundles age out, so there is no window where the
field the UI reads is absent.
## Verification
- `pnpm typecheck`: clean.
- Affected unit tests pass (asset utils, store, media/model scans,
widget composables).
- `grep -rn asset_hash src/`: zero matches.
## Summary
When a visitor arrives at the cloud product with
`utm_source=comfy.desktop`, register `source_app` and
`desktop_device_id` as PostHog super-properties and persist them onto
the person on identify.
Backend-fired billing events (Stripe webhook →
`billing:subscription_created`) then inherit the desktop attribution via
person-on-events, closing the cross-session gap where browser-side utm
capture and backend webhook events live on different `distinct_id`s.
## Why
The desktop app appends
`?desktop_device_id=<id>&utm_source=comfy.desktop` to its cloud links.
`utm_source` is auto-captured by posthog-js as a session super-property,
but arbitrary query params like `desktop_device_id` are ignored. Without
this, cross-session Desktop→Cloud sub attribution silently shows zero.
Confirmed empirically: across 24h of recent billing events,
`person.$initial_utm_source = 'comfy.desktop'` matched 0 rows, because
users had visited the cloud surface before they ever launched desktop.
Person-property based join via this PR is the durable fix.
## Test plan
- [x] Unit tests for: no utm, wrong utm, utm with device id, utm without
device id, person.set after identify, no-op for non-desktop visitors
- [x] `pnpm vitest run PostHogTelemetryProvider.test.ts` — 28/28 pass
- [x] `pnpm typecheck` — clean
- [x] `pnpm lint` — clean
- [ ] Manual verification post-merge: visit cloud.comfy.org with
`?utm_source=comfy.desktop&desktop_device_id=test-abc`, log in, check
PostHog person profile gains `desktop_device_id`,
`last_seen_via_desktop`, `first_seen_via_desktop`, `source_app`
## Summary
Simplifies the error overlay so it presents one clear title, one clear
message, and one stable details action instead of rendering a list of
per-error messages.
## Changes
- **What**: Extracts the error overlay view model into
`useErrorOverlayState`, adds focused unit coverage for the overlay copy
resolution rules, and updates the overlay E2E coverage to match the new
behavior.
- **Breaking**: None.
- **Dependencies**: None.
### Behavior changes
- The overlay body no longer renders a `<ul>` of individual error
messages. It now always renders a single paragraph message.
- Single-error overlays now prefer toast-specific copy when it exists.
For execution errors, the overlay resolves the message in this order:
`toastMessage`, `displayMessage`, raw `message`, group `displayMessage`,
then group `displayTitle`. The title resolves from `toastTitle`, then
`displayTitle`, then the group title.
- Single non-execution groups use group-level toast/display copy. This
lets grouped error types supply overlay-friendly copy without the
overlay needing to understand each card implementation.
- Multiple-error overlays now ignore individual error item copy in the
overlay itself. The header becomes the pluralized count title, for
example `7 errors found`, and the body becomes the fixed guidance
message: `Resolve them before running the workflow.`
- The overlay is hidden if the store reports an error count but no
resolved overlay message exists. This avoids rendering a visible shell
with an empty body.
- The action button no longer varies by error type in normal app mode.
Missing nodes, missing models, missing media, swap nodes, validation
errors, and runtime errors all use `View details` instead of labels like
`Show missing nodes`, `Show missing models`, `Show missing inputs`, or
`See Errors`.
- App mode keeps its existing `Show errors in graph` action label.
- The overlay width now keeps the previous width as its minimum and
allows a wider maximum, reducing avoidable wrapping in longer error
headers.
- The live region was softened from an assertive alert-style
announcement to `role="status"` with `aria-live="polite"` so updates
such as count changes are less disruptive.
### Tests
- Adds component coverage for the rendered overlay shape and app-mode
action label.
- Adds composable coverage for single execution errors, runtime errors,
grouped missing media errors, multiple-error aggregate copy, hidden
empty-message state, and display-copy fallback behavior.
- Updates `errorOverlay.spec.ts` so the E2E suite checks the new
single-message overlay, the stable `View details` action, and the fixed
multiple-error body guidance.
- Removes the old type-specific button-label E2E expectations because
that branch no longer exists in product behavior.
### Follow-up PR
A follow-up PR is stacked on top of this one:
`jaeone/fe-816-missing-resource-error-messaging`.
That follow-up will wire missing resource error resolvers into the copy
model consumed here. It covers missing node packs, missing models,
missing media, and swap-node groups, including the group-level
`toastTitle`, `toastMessage`, `displayMessage`, `displayDetails`, and
item label copy those cards need. This PR intentionally keeps the
overlay behavior separate so it can merge first without depending on the
missing-resource resolver copy.
## Review Focus
- Please check the single-error versus multiple-error overlay behavior,
especially the fallback order for execution error copy.
- Please check that the `View details` action is now intentionally
error-type agnostic in normal app mode while app mode keeps `Show errors
in graph`.
- Please check the empty-message guard and the requirement that a
single-error overlay only resolves a single group when the total error
count and group list agree.
- Please check the E2E reduction: the old type-specific action-label
assertions were removed because the UI branch they tested was removed.
## Screenshots (if applicable)
N/A
## Summary
Fix Cloud media loader widgets so `LoadImage`, `LoadVideo`, and
`LoadAudio` resolve their default values from Cloud input assets instead
of blindly accepting backend `object_info` combo options. When no
matching Cloud input asset exists, the widgets now start empty instead
of selecting a server-only value that immediately trips missing-input
detection.
## Changes
- **What**: Cloud media input widgets now derive their available values
from `assetsStore.inputAssets`, filtered to the node's media type and to
assets with a valid `asset_hash`.
- **What**: Cloud media defaults now prefer an explicit default only
when it matches an available Cloud input asset hash or name, then fall
back to the first matching Cloud input asset, and otherwise use an empty
value.
- **What**: The media path keeps the existing model-widget
implementation style by resolving Cloud asset state through the store
internally, while preserving media-specific hash/name matching because
media widgets submit Cloud `asset_hash` values.
- **What**: Added regression coverage for adding empty Cloud
`LoadImage`, `LoadVideo`, and `LoadAudio` nodes when backend
`object_info` advertises server-only media options.
- **What**: Expanded media widget unit coverage for image/video/audio
inputs, empty defaults, first-asset fallback, default-by-hash matching,
default-by-name matching, hashless asset filtering, unrelated media
filtering, dynamic values, option labels, lazy input loading, and
`control_after_generate` wiring.
- **What**: Kept existing OSS and Cloud runtime missing-media E2E
coverage, with Cloud fixtures consistently using the local setup backend
for `object_info` so tests do not depend on live Cloud backend startup
details.
- **Breaking**: None.
- **Dependencies**: None.
## Review Focus
- Cloud media loader defaults should no longer be sourced from backend
file lists unless the value also corresponds to a Cloud input asset.
- Empty Cloud input-asset libraries should produce empty media widget
values, not missing-input errors at node creation time.
- Model asset-browser behavior is intentionally unchanged. The media
path mirrors the store-access style, but media defaults still resolve to
asset hashes because those are the values submitted by Cloud media
widgets.
- The Cloud E2E fixture stubs bootstrap endpoints and routes
`object_info` through the local setup backend. This keeps the test
focused on frontend behavior while still using realistic node
definitions.
## Testing
- `pnpm exec oxfmt
browser_tests/tests/propertiesPanel/errorsTabMissingMediaRuntime.spec.ts
src/renderer/extensions/vueNodes/widgets/composables/useComboWidget.test.ts
src/renderer/extensions/vueNodes/widgets/composables/useComboWidget.ts`
- `pnpm lint`
- `pnpm typecheck`
- `pnpm typecheck:browser`
- `pnpm exec vitest run
src/renderer/extensions/vueNodes/widgets/composables/useComboWidget.test.ts`
- `PLAYWRIGHT_TEST_URL=http://127.0.0.1:5174
PLAYWRIGHT_SETUP_API_URL=http://127.0.0.1:8188 pnpm exec playwright test
browser_tests/tests/propertiesPanel/errorsTabMissingMediaRuntime.spec.ts
--project=chromium --workers=1`
- `PLAYWRIGHT_TEST_URL=http://127.0.0.1:5175
PLAYWRIGHT_SETUP_API_URL=http://127.0.0.1:8188 pnpm exec playwright test
browser_tests/tests/propertiesPanel/errorsTabMissingMediaRuntime.spec.ts
--project=cloud --workers=1`
- `git diff --check`
- `pnpm knip`
- `.claude/skills/reviewing-unit-tests/SKILL.md` red-flag review
## Screenshots
Before
https://github.com/user-attachments/assets/5df04036-d15c-4f94-bdcd-df8b26a29329
After
https://github.com/user-attachments/assets/abe7caf5-a83b-4960-aa6f-65a377424a85
## Summary
On media nodes (Load/Preview/Save Image), the right-click context menu
buried the image actions at the very bottom — and `Open Image` sat
*second* within that group, behind `Open in Mask Editor`. In legacy
LiteGraph (Node 1.x) `Open Image` was the first menu item
(`options.unshift`), so the Vue menu was a regression in muscle memory.
This hoists the image-action group (`Open Image`, `Open in Mask Editor`,
`Copy Image`, `Paste Image`, `Save Image`) to a new top section of the
menu, with `Open Image` first. Because these labels only ever appear for
media nodes, non-media node menus are unchanged (keeps the core menu
order stable — per Alex Tov's request in the FE-839 thread).
- FE-839
- Related: DES-368 (lightbox idea this replaces)
## Implementation
- `contextMenuConverter.ts`: move the image group to the front of
`MENU_ORDER` (new "Section 0"), shift `getSectionNumber` boundaries, and
change the section-divider sentinel `lastSection` from `0` to `-1`
(Section 0 is now a real section, so the old `> 0` guard would have
dropped the divider before `Rename`).
- `useImageMenuOptions.ts`: push `Open Image` before `Open in Mask
Editor` for source/display consistency.
## Red-Green Verification
| Commit | Unit CI | Result |
|--------|---------|--------|
| `test: add failing tests …` | [run
26749384308](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/26749384308)
| Red — fails on `expected 'Rename' to be 'Open Image'` |
| `fix: surface image actions …` | [run
26749817184](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/26749817184)
| Green — passing |
## Before / After
Right-click on a media node (Load Image with `example.png`):
- **Before:** `Open Image` buried near the bottom, second within its
group.
- **After:** image actions group surfaced at the top, `Open Image`
first; core order (Rename/Copy/…) unchanged below the divider.
| Before (`main`) | After (this PR) |
| --- | --- |
| <img width="460" alt="Before: image actions buried at the bottom of
the menu, Open in Mask Editor above Open Image"
src="https://github.com/user-attachments/assets/2d0a6345-6cbb-4391-8cee-60632a6af72f"
/> | <img width="460" alt="After: image actions hoisted to the top of
the menu, Open Image first"
src="https://github.com/user-attachments/assets/6af0840f-0623-41f2-9fa1-b4a16798f9a5"
/> |
## Test Plan
- [x] CI red on test-only commit
- [x] CI green on fix commit
- [x] Unit regression in `contextMenuConverter.test.ts` (6 tests: Open
Image first / image group above Rename / divider between /
Copy<Paste<Save / core order preserved / non-media unchanged)
- [x] Manual verification in live app (before/after)
## Summary
Adds a new `app:node_added` PostHog event that fires whenever a user
adds a node to the canvas, tagged with a `source` discriminator
(sidebar_drag, search_modal, paste, programmatic, unknown). Lets us
measure how users compose graphs — which we can't infer from any
existing event.
## Changes
- **What**: Subscribes to `LGraph.onNodeAdded` via
`installNodeAddedTelemetry()`. Source is threaded through call sites via
a synchronous module-level flag (`withNodeAddSource`) — `addNodeOnGraph`
signature is unchanged.
- Wired sources: sidebar drag (3 sidebars + canvas drop), search-modal
popover, vintage clipboard paste, programmatic adds (job menu, media
asset actions). Unrecognized paths fall through as `unknown`.
- **Skip on workflow load**: `ChangeTracker.isLoadingGraph` gates out
the bulk-add path. `workflow_imported` already covers that population,
and 4M imports/month × ~50 nodes would dwarf user-initiated signal.
## Review Focus
- Module-level flag is synchronous-only — the source is read inside the
synchronous `onNodeAdded` callback that fires during `graph.add()`.
Async code (e.g. `createNode`'s `await setTimeout(0)`) doesn't
interleave because the wrap is around `graph.add`, not the await.
- Unit test covers: fires with current source, defaults to 'unknown',
skips during workflow load, preserves existing onNodeAdded subscriber.
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
The multi-select branch of onPointermove started a node drag whenever
LMB + shift/ctrl/meta was held during pointermove, even when pointerdown
had never reached the node (because a child widget swallowed it with
@pointerdown.stop). In Preview3D/Load3D, shift+drag inside the threejs
scene therefore dragged the underlying Vue node.
Gate the multi-select branch on dragGuard.wasDragged(event) — same gate
the regular branch already uses. dragGuard.start is only recorded by
onPointerdown, so a widget that swallows pointerdown now naturally opts
itself out of node drag-start without having to also swallow pointermove
(which would break libraries like three.js OrbitControls that listen for
pointermove on document).
## Screenshots (if applicable)
before
https://github.com/user-attachments/assets/b5faa803-5993-4341-a1d0-7ec980362344
after
https://github.com/user-attachments/assets/f7367e61-6194-4e16-9713-c398f989d26b
## Summary
When the cloud `getJobDetail` returns two output records that resolve to
the same composite key `${nodeId}-${subfolder}-${filename}`,
`mapOutputsToAssetItems` in
`src/platform/assets/utils/outputAssetUtil.ts` produces two `AssetItem`s
with the same synthetic id. The Vue `v-for :key="item.key"` in
`src/components/common/VirtualGrid.vue:10` collides, Vue reuses one DOM
node for the colliding rows, and the user sees one asset visibly
duplicate and progressively replace its neighbours while scrolling
through an expanded large job in the media asset panel — symptom matches
FE-297 in both list and grid views (both views derive from the same
`displayAssets` populated by `resolveOutputAssetItems`).
Fix tracks composite keys per resolved job and skips subsequent records
that collide on the same key. Treats the composite key as the canonical
identity of an output, so each rendered row is unique in both views
without changing public id semantics for non-colliding inputs.
- Fixes FE-297
- Source: [Slack
#bug-dump](https://comfy-organization.slack.com/archives/C0A4XMHANP3/p1777047001770899)
## Red-Green Verification (unit)
| Commit | Purpose | CI |
| --- | --- | --- |
|
[`b263af29b`](https://github.com/Comfy-Org/ComfyUI_frontend/pull/11716/commits/b263af29b)
test: FE-297 add failing test for asset id collision on duplicate output
key | Proves the test catches the regression | 🔴 [Red run
25038514049](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/25038514049)
— `FE-297: deduplicates outputs that share the same composite output
key` failed with `expected length 2 but got 3` |
|
[`af38cad1d`](https://github.com/Comfy-Org/ComfyUI_frontend/pull/11716/commits/af38cad1d)
fix(assets): dedupe outputs by composite key to prevent visual collapse
on scroll | Proves the fix resolves it | 🟢 [Green run
25038832343](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/25038832343)
— all unit tests pass |
Local verification (`pnpm vitest run
src/platform/assets/utils/outputAssetUtil.test.ts`):
- On red commit: `FE-297: deduplicates outputs that share the same
composite output key` fails with `expected length 2 but got 3`.
- On green commit: all 8 tests pass; broader `pnpm vitest run
src/platform/assets/` reports 390/390 pass.
## Browser-level Verification (e2e)
[`c5f80e225`](https://github.com/Comfy-Org/ComfyUI_frontend/pull/11716/commits/c5f80e225)
adds `browser_tests/tests/sidebar/assets-fe297-dedupe.spec.ts`. The spec
mocks `/api/jobs` + `/api/jobs/{jobId}` so the assets sidebar receives a
5-output stack job whose detail payload contains two records sharing
`9--duplicate_00002_.png`. It expands the stack into folder view and
reads the underlying `VirtualGrid` row total from the top/bottom spacer
heights so the assertion does not depend on viewport size, scroll
virtualization, or Vue's same-key DOM reuse.
Locally validated red→green (`pnpm dev` + local ComfyUI on :8188, `pnpm
exec playwright test … --project=cloud`):
| Source | `totalRows` | rendered tile labels | result |
| --- | --- | --- | --- |
| Red (dedup removed from `mapOutputsToAssetItems`) | **5** |
`[duplicate_00002_.png, duplicate_00002_.png, distinct_00004_.png]` (two
adjacent collisions) | 🔴 `Expected: 4 / Received: 5` |
| Green (HEAD) | **4** | `[duplicate_00002_.png, distinct_00004_.png,
distinct_00003_.png]` (no collisions) | 🟢 `1 passed` |
Manual repro of the same flow against the running dev server (Chrome
DevTools, runtime `fetch` interceptor for `/api/jobs/<id>`) reproduces
the FE-297 symptom directly: with the fix removed, the folder view
renders **two consecutive cards both labelled `duplicate_00002_.png`**;
with the fix applied that second slot is replaced by the next distinct
file.
## Cloud Prod Verification (unmocked)
Verified against a real cloud prod job
(`22dda683-1634-4120-8a7d-233cff28e07e`) whose `/api/jobs/{id}` payload
organically contains the FE-297 trigger condition.
Raw cloud response analysis: **35 output records across 27 nodes, 34
unique composite keys, 1 colliding key**
(`103--cbbce08934d17e85987b09824ae519822e4462b4294fc52fc40dca8d5b096323.png`
appears twice — same nodeId/subfolder/filename emitted from two distinct
output records).
Expanded folder view on local FE running this branch against cloud prod
backend:
| Measurement | Value | Expectation |
| --- | --- | --- |
| `outputCount` (backend) | 35 | — |
| Unique composite keys (backend) | 34 | (35 - 1 collision) |
| VirtualGrid rendered cells (`totalRows * colCount` via spacer height)
| **34** | matches dedupe target |
| Simultaneously-visible duplicate labels | 0 | no Vue `:key` collision
|
This is the first visual confirmation of FE-297 against actual prod data
rather than synthetic/mocked payloads. The block had been pending on
FE-844 — cloud `/api/jobs/{id}` returns `text: [null]` for empty
subgraph promoted text outputs, which the FE Zod schema rejects, causing
`fetchJobDetail` to return `undefined` and the folder view to collapse
to the cover preview only. With [PR
#12449](https://github.com/Comfy-Org/ComfyUI_frontend/pull/12449)
(FE-844) applied locally, the job-detail response reaches
`resolveOutputAssetItems`, FE-297's dedupe runs, and the 35→34 collapse
is observable end-to-end.
## Test Plan
- [x] New unit regression covering composite-key collision in
`mapOutputsToAssetItems`
- [x] Existing `outputAssetUtil` tests still pass (`job-1-1-sub-a.png`
etc. id format unchanged for non-colliding inputs)
- [x] Broader asset platform suite (`src/platform/assets/`) passes
- [x] CI red-green sequence captured (links above)
- [x] Browser-level e2e (`assets-fe297-dedupe.spec.ts`) red→green
validated locally; will run in CI on this commit
- [x] Manual repro on dev server confirms the duplicate-card symptom
disappears with the fix
- [x] Unmocked cloud-prod repro: real 35-output job with 1 organic
composite-key collision renders 34 cells, 0 duplicate labels
simultaneously visible (requires
[#12449](https://github.com/Comfy-Org/ComfyUI_frontend/pull/12449) for
job-detail fetch to succeed)
## Summary
cloud.comfy.org shows the old yellow-on-blue ComfyUI mark as its
favicon. Root cause: `manifest.json` points at `comfy-logo-single.svg`
(old `#172DD7` blue logo), and older deployed builds set no static
`<link rel="icon">`, so the browser uses the manifest icon for the tab.
Point the manifest at new-brand dark+yellow icons.
## Changes
- **What**: `manifest.json` icons now reference new `comfy-icon-192.png`
/ `comfy-icon-512.png` (dark `#211927` + yellow `#F2FF59`, full-bleed
for `maskable` safe zone) instead of the old blue
`comfy-logo-single.svg`.
- **Breaking**: none.
## Review Focus
- Pairs with #12537 (static `favicon.ico` link, merged) — together the
tab favicon and the PWA/install icon are both the new brand.
- This does NOT change `comfy-logo-single.svg` itself, which is still
used as the in-app header logo (`ComfyOrgHeader.vue`) and the cloud
subscription redirect view — those remain the old blue mark and can be
updated separately if desired.
- Note: cloud.comfy.org runs a pinned/older frontend build; this (and
#12537) only take effect once cloud bumps its frontend version.
## Screenshots (if applicable)
*PR Created by the Glary-Bot Agent*
---
## Summary
The
[`pr-report.yaml`](https://github.com/Comfy-Org/ComfyUI_frontend/blob/main/.github/workflows/pr-report.yaml)
workflow is dispatched via `workflow_run` after `CI: Size Data`, `CI:
Performance Report`, or `CI: E2E Coverage` complete. Those upstream
workflows also run on push to `main`, which dispatches `PR: Unified
Report` on the `main` branch head, producing failed runs like [run
26913874399](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/26913874399/job/79398707144).
The existing job-level guard (`github.event.workflow_run.event ==
'pull_request'`) doesn't always prevent the runner from spinning up, so
noisy failed runs still appear under the workflow's history on `main`.
## Change
Add `branches-ignore: [main]` to the `workflow_run` trigger so the
workflow no longer dispatches when the upstream run's head branch is
`main`.
```yaml
on:
workflow_run:
workflows: ['CI: Size Data', 'CI: Performance Report', 'CI: E2E Coverage']
types:
- completed
branches-ignore:
- main
```
## Tradeoff to flag
`workflow_run.branches-ignore` filters on the triggering workflow run's
head branch. For PRs, that's the PR's source branch. A fork PR whose
source branch is literally named `main` (e.g., a fork opened from its
default branch) will no longer get a unified report comment. This is
uncommon for contributors who follow the usual feature-branch workflow,
but if preserving comments for fork-from-`main` PRs matters, the
alternative is to leave the dispatch in place and rely solely on the
existing job-level `if` guard.
Co-authored-by: Glary-Bot <glary-bot@users.noreply.github.com>
## Summary
Centralize pnpm-run Node options so Node 25 does not shadow happy-dom
storage and build scripts keep the existing heap limit.
## Changes
- **What**: Adds workspace-level `nodeOptions` that preserve
caller-provided `NODE_OPTIONS`, disable Node's native Web Storage, and
set `--max-old-space-size=8192`.
- **What**: Removes duplicate script-local heap `NODE_OPTIONS` from
build scripts now covered by pnpm.
- **Dependencies**: None.
## Review Focus
Check whether applying these Node options to all pnpm-run Node
subprocesses is acceptable versus keeping flags script-local.
## Screenshots (if applicable)
Not applicable.
*PR Created by the Glary-Bot Agent*
---
## Summary
The node-canvas COLOR widget (`WidgetColorPicker.vue`) already migrated
off PrimeVue; this PR finishes FE-804 by porting the two remaining
`primevue/colorpicker` consumers — `FormColorPicker.vue` (settings form
`type: 'color'`) and `ColorCustomizationSelector.vue`
(folder-customization dialog) — to the in-house Reka-UI based
`ColorPicker`. The now-dead PrimeVue overlay workaround in
`CustomizationDialog.vue` is removed.
After this lands there are **zero `primevue/colorpicker` imports left**
in `src/`.
## Changes
- **What**: `FormColorPicker.vue` swaps `primevue/colorpicker` +
`primevue/inputtext` for the in-house `ColorPicker` + `Input`. The
legacy "hex without `#`" storage contract (e.g. `load3d`'s
`BackgroundColor` default `'282828'`) is preserved on read and on write.
- **What**: The text input now uses a separate draft value and only
commits on blur / Enter when the input is a complete 6- or 8-digit hex.
This fixes the "type `#f` and watch it snap to black" regression that a
naive shared-`v-model` implementation re-introduces.
- **What**: `disabled`, `id`, and `aria-labelledby` are now explicit
props on `FormColorPicker` and are forwarded to both children. The
custom `ColorPicker` learned a `disabled` prop that propagates to its
`<PopoverTrigger>` button.
- **What**: `ColorCustomizationSelector.vue` swaps
`primevue/colorpicker` for the in-house `ColorPicker` (still uses
`primevue/selectbutton` — intentionally out of scope per FE-804's title;
`SelectButton` migration is a separate effort).
- **What**: `CustomizationDialog.vue` drops the `.p-colorpicker-panel,
.p-overlay, .p-overlay-mask` `pointer-down-outside` guard. With PrimeVue
ColorPicker gone, no descendant of this dialog teleports an overlay to
`<body>` anymore.
- **What**: Updates two affected browser tests — `extensionAPI.spec.ts`
(the `disabled` attr smoke check) and `sidebar/nodeLibrary.spec.ts` (the
bookmark color customization flow) — to target the new picker via stable
accessible names (`role="slider"` + i18n aria-label `Color saturation
and brightness`) and the `.color-picker-wrapper > button` trigger. The
disabled-attr eval helper now handles `HTMLButtonElement` in addition to
`HTMLInputElement`.
- **What**: Adds `FormColorPicker.test.ts` with focused regression
coverage for the manual-entry contract: legacy no-`#` storage
round-trip, no commit on partial hex, revert on partial-then-Enter,
8-digit alpha hex, and `disabled` propagation.
- **Dependencies**: none added; removes two PrimeVue imports.
- **Breaking**: no breaking change to the documented FormItem `'color'`
setting contract. Manual-entry semantics change: typing partial hex no
longer immediately writes mangled state — it commits on blur or Enter
when the value fully parses. Existing settings values are unaffected.
## Verification
- `pnpm typecheck` clean
- `pnpm typecheck:browser` clean
- `pnpm exec eslint` on every touched file clean
- `pnpm test:unit` over the affected directories — **216 passed**
- Manual QA via Playwright against the running dev server:
- Registered a test extension with `type: 'color'` + a `disabled: true`
variant
- Confirmed the new picker renders, opens its Reka popover, and the
disabled row has `button.disabled === true` and `input.disabled ===
true`
- Confirmed partial hex (`#ab`) does **not** clobber the swatch
- Confirmed `#1133aa` + blur commits and round-trips through the picker
## Review focus
1. The manual-entry commit gate in `FormColorPicker.vue`
(`commitDraft()` + `FULL_HEX`) — is the regex strict enough? Should
3/4-digit shorthand hex be accepted on commit too? PrimeVue accepted
3-digit shorthand; the existing `toHexFromFormat()` already does, so
adding `|[0-9a-f]{3}|[0-9a-f]{4}` is a one-line change if reviewers want
parity.
2. Disabled-attr E2E selector swap (`.p-colorpicker-preview` →
`.color-picker-wrapper > button`) + the eval-helper update that now
handles `HTMLButtonElement` in addition to `HTMLInputElement`. The
structural selector matches what PrimeVue had; happy to add a
`data-testid` if reviewers prefer.
3. `ColorPicker.vue` gained a `disabled` prop — kept explicit (peer of
`class`) to match the existing prop shape rather than forwarding through
`$attrs`.
## Follow-up (NOT in this PR)
Discussed in-thread — the **Reka-UI `ColorField` migration** (full
picker rebuild) and the **Kijai regression suite** for alpha-disabled +
manual-entry on the node-canvas COLOR widget belong in a separate,
scoped PR alongside the `ColorInputSpec` schema additions (`hasAlpha`,
`format`). The custom picker also has a known lossy HSV-percent
quantization (e.g. `#1133aa` round-trips to `#1033a9`) that pre-dates
this PR and would be addressed by the Reka primitives.
- Fixes FE-804
## Screenshots
---------
Co-authored-by: Glary-Bot <glary-bot@users.noreply.github.com>
#12532 caused some regressions in security audits. I've updated `vitest`
resolve a [newly reported
vulnerability](https://github.com/Comfy-Org/ComfyUI_frontend/security/dependabot/166)
and performed and re-resovled the lockfile to clear out the audit
warnings.
Sanity check: `pnpm audit` passes with the lock-file introduced by this
PR, but multiple packages are showing a downgrade in version. Second
opinions would be appreciated.
*PR Created by the Glary-Bot Agent*
---
## Summary
Mirrors the existing Impact affiliate wiring for the new Rewardful
affiliate network. The client reads `window.Rewardful.referral` when
`getCheckoutAttribution()` runs at checkout time and emits it as a new
optional `rewardful_referral` field on `CheckoutAttributionMetadata`.
The Go backend consumes this field separately and passes it to Stripe as
`ClientReferenceID` on the Checkout Session create call — that wiring
lives in a sibling PR on `Comfy-Org/cloud` (services/comfy-api) and is
the path that actually credits affiliate commissions for Stripe
subscriptions.
Per Rewardful's docs for server-side Stripe Checkout Sessions, the
GTM-loaded Rewardful JS handles cookie persistence on the client but
**cannot** attribute Checkout Sessions on its own — the merchant must
explicitly pass the referral UUID server-side as `client_reference_id`.
## Why this is the simplest possible client-side change
- Rewardful's JS (loaded via GTM) owns its own cookie persistence, so
unlike Impact (where we capture `im_ref` from URL params and persist to
localStorage ourselves), we just read `window.Rewardful.referral` at
checkout time. No URL fallback, no localStorage handling.
- If Rewardful's script hasn't loaded or the user didn't come from an
affiliate link, the field is simply omitted from the payload.
- Adds a narrow `RewardfulGlobal` interface to `global.d.ts` (`referral`
plus optional `affiliate`/`campaign` metadata Rewardful exposes) so
`window.Rewardful` is typed everywhere it's accessed.
- 4 new unit tests covering: present, absent, empty-string, and
alongside Impact attribution. The existing 10 Impact/UTM tests are
untouched.
## Files touched
| File | Change |
|---|---|
| `global.d.ts` | Add `RewardfulGlobal` interface + `Rewardful?:` on
`Window` |
| `src/platform/telemetry/types.ts` | Add `rewardful_referral?: string`
to `CheckoutAttributionMetadata` |
| `src/platform/telemetry/utils/checkoutAttribution.ts` | Read
`window.Rewardful?.referral` in `getCheckoutAttribution()` |
| `src/platform/telemetry/utils/__tests__/checkoutAttribution.test.ts` |
4 new tests + `window.Rewardful = undefined` reset in `beforeEach` |
## Cross-PR dependency
Needs the sibling [`Comfy-Org/cloud`
PR](https://github.com/Comfy-Org/cloud/pulls?q=is%3Apr+rewardful)
(branch `glary/rewardful-affiliate-tracking`) to actually credit
referrals. **This PR is safe to ship independently** — the field is just
ignored by the existing comfy-api endpoint until that PR lands.
## Verification
- `pnpm typecheck` — clean
- `pnpm test:unit src/platform/telemetry/utils` — 14/14 passing (10
prior + 4 new)
- `pnpm test:unit` (full repo) — passing
- `pnpm lint` — 3 warnings, 0 errors (warnings pre-existing on `main`)
- `pnpm format:check` — clean
- `pnpm knip` — clean (1 pre-existing unrelated warning)
- `pnpm exec vite build` — successful (7.85s)
Related: FE-704 (Finish affiliate pages PRs) for context on the broader
affiliate launch.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-12311-feat-telemetry-capture-Rewardful-referral-on-checkout-attribution-3626d73d365081beb03afb2e000c83a6)
by [Unito](https://www.unito.io)
---------
Co-authored-by: glary-bot <glary-bot@comfy.org>
Co-authored-by: Benjamin Lu <benjaminlu1107@gmail.com>
## Summary
Adds a `missing_node_packs` property to the existing
`app:workflow_imported` PostHog event so we can see *which custom node
packs* a workflow depends on, not just the raw node names.
## Changes
- **What**: Group missing-node entries by their `cnrId` (already present
on each node's properties) and attach as `missing_node_packs: [{
pack_id, node_types }]`. Pure helper, fully sync, no network calls.
Nodes without a `cnrId` bucket under `pack_id: 'unknown'` so we can size
that population separately.
- Fires on every import path (drag-drop, file picker, shared URL) —
`open_source` already disambiguates.
## Review Focus
- The `'unknown'` bucket is intentional. It tells us how often workflows
arrive without pack metadata, which is itself useful.
- No async lookups — if `cnrId` isn't in the JSON, we don't go ask the
registry. Keeps import fast and offline-safe.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Reads the asset content hash from a new `hash` field, preferring it and
falling back to the existing `asset_hash` alias everywhere asset hashes
are consumed. This is the frontend half of converging the asset
content-hash field name onto `hash` (which the asset content-addressing
endpoints — `from-hash`, `hash/{hash}` — already use).
## Why this is safe to land now (order-independent)
- Against the current backend (emits only `asset_hash`), `hash` is
absent, so every read falls back to `asset_hash` → **byte-identical
behavior**.
- Once the backend emits `hash`, the FE uses it — which then lets the
backend drop `asset_hash` without breaking any read.
So this can merge independently of the backend; nothing is gated on it.
## What changed
- Add `hash` to the asset zod schema (`AssetItem`) and the local
`AssetRecord` type.
- Migrate all response reads of `asset_hash` → `hash ?? asset_hash`
(combo widget, widget select items, missing-media/missing-model scans,
media asset actions, preview util, metadata util, assets store).
- The `isCloud` storage-model branches (cloud = hash-as-filename, local
= name) keep their gate — only the field source changes. Removing those
conditionals is a separate behavioral change, not part of this rename.
- The `fetchAssets({ asset_hash })` request param is intentionally left
as-is; it flips to `hash` only after the backend accepts the new param
name.
## Test plan
- `vue-tsc --noEmit` — 0 errors
- `eslint` — clean
- `vitest run` on assets / missingMedia / missingModel — 775 tests pass
---------
Co-authored-by: GitHub Action <action@github.com>
*PR Created by the Glary-Bot Agent*
---
Adds an **Affiliate Program** entry under the Resources column of the
site footer, positioned immediately after the YouTube link. Links to
`/affiliates` via the existing locale-invariant `routes.affiliates`
helper.
### Stacked on #12002
This PR is branched off `glary/affiliates-landing-page` (PR #12002), not
`main`, because:
- `routes.affiliates` and the `/affiliates` page itself are added by
#12002 and aren't on `main` yet.
- Linking to `/affiliates` from the footer before #12002 merges would
404 in production.
GitHub will auto-rebase this PR onto `main` once #12002 merges.
**Re-target this PR's base from `glary/affiliates-landing-page` to
`main` before reviewing for merge** (or simply merge #12002 first and
GitHub will switch the base for you).
### Diff
```
apps/website/src/components/common/SiteFooter.vue +4
apps/website/src/i18n/translations.ts +4
```
- New `footer.affiliateProgram` i18n key. English-only per the go-live
direction for affiliate-related copy (zh-CN mirrors EN to satisfy the
dictionary's `Record<Locale, string>` shape; matches how `nav.youtube`
and other proper-noun footer entries handle this).
- New `FooterLink` entry in `topColumns[1].links` (the Resources
column), after the YouTube entry. Internal route, so no `external:
true`.
### Local verification
- `pnpm typecheck`: 0 errors
- `pnpm build`: 380 pages, footer renders `Affiliate Program` →
`/affiliates` in both desktop and mobile layouts, on `/`, `/about`,
`/zh-CN/`, etc. Link ordering in Resources: `Blog → Discord → GitHub →
Docs → YouTube → Affiliate Program` (verified by parsing the built HTML)
- `pnpm test:unit`: passing (no SiteFooter unit test exists; it's
exercised through e2e/visual coverage)
- `pnpm lint`: no new warnings (3 pre-existing on unrelated files)
- `pnpm format:check`: clean
- `pnpm knip`: clean
- `pnpm exec tsx scripts/check-unused-i18n-keys.ts`: clean (new key is
used)
### Out of scope
- No new Linear ticket (this is a follow-up to the affiliate-program
go-live work tracked under FE-704).
- Header nav / mobile menu changes — only the footer was requested.
Co-authored-by: Glary-Bot <glary-bot@users.noreply.github.com>
## Summary
Redesigns the cloud login and signup screens with a new split-screen
template featuring hero carousel on the right.
## Changes
- **What**:
- New `CloudHeroCarousel` component (product logo chips for Gemini,
Grok, Seedance)
- `CloudTemplate` restructured: removed video background and
`BaseViewTemplate` wrapper; new shell uses `bg-charcoal-750` /
`text-sand-500` and renders the carousel in the right column at `lg+`
- `CloudLoginView` and `CloudSignupView` restyled to match the new dark
shell (sand/azure/smoke tokens, `shadow-inset-highlight` OAuth buttons,
brand-yellow free-tier badge)
- `CloudSignInForm` submit button restyled to match the OAuth secondary
style
- `CloudLogo` switched from `<img>` to inline SVG with `currentColor` +
`aria-label`
- Three new logo components (`GeminiLogo`, `GrokLogo`, `SeedanceLogo`) —
inline SVG, `aria-hidden`, `currentColor`
- Theme tokens added in `style.css`: `--color-charcoal-750`,
`--color-sand-500`, `--shadow-inset-highlight`
- i18n keys added under `cloudHero.*` for carousel titles, descriptions,
and pager labels
- Hero image assets added under
`src/platform/cloud/onboarding/assets/hero/`
## Screenshots
<img width="1470" height="838" alt="image"
src="https://github.com/user-attachments/assets/747bfc98-f605-4904-9a3f-3ba0de88573b"
/>
---------
Co-authored-by: Deep Mehta <42841935+deepme987@users.noreply.github.com>
Co-authored-by: Austin <austin@comfy.org>
*PR Created by the Glary-Bot Agent*
---
Conversion-oriented English landing page that drives applications to the
Comfy Affiliate Program Google Form. Shipped behind `noindex` while copy
and assets are finalized — a follow-up PR will flip it indexable and add
the zh-CN locale.
Mirrors the type scale, brand tokens, and noindex/sitemap/robots
conventions from the [/affiliates/terms PR
(#11954)](https://github.com/Comfy-Org/ComfyUI_frontend/pull/11954) so
the two pages feel like a set. The footer's "Read the affiliate program
terms" link points at `/affiliates/terms`, which lands with #11954.
## What's in the box
Sections (in render order): hero → trust band → how-it-works →
who-we're-looking-for → program details → brand assets → FAQ → footer
CTA.
- **i18n** — Copy lives under `affiliate-landing.*` in
`src/i18n/translations.ts` (en only; zh-CN values mirror en until a
localized version lands, so non-engineers can edit copy without touching
components).
- **Component reuse audit** — Reuses `common/FAQSection`,
`common/BrandButton`, `common/SectionHeader`, `common/SectionLabel`
verbatim. Sections without a clean primitive fit (split hero, trust
band, 3-step flow, audience list, details table, brand-asset grid,
footer CTA) render inline with brand tokens rather than forking new
shared components.
- **Brand assets** — Wired via a config object in
`components/affiliates/brandAssets.ts` so 728×90 / 300×250 / 160×600 /
1200×628 banners can be dropped in later without code changes. Live
tiles for `/icons/logo.svg` and `/icons/logomark.svg`; placeholder
"Coming soon" tiles for the four banner sizes.
- **CTA** — `Apply Now` → `https://forms.gle/RS8L2ttcuGap4Q1v6`, opens
in new tab with `target="_blank"` and `rel="noopener noreferrer"`. Hero
and footer-CTA both use it.
- **Hero media slot** — Wired as a named slot (`<slot name="media">`)
with a static node-graph SVG fallback, so a video can be dropped in
later via the page without component changes.
- **FAQ structured data** — Page emits `schema.org/FAQPage` JSON-LD so
it's ready for SEO when `noindex` flips off.
- **noindex** — `<meta name="robots" content="noindex, nofollow">` via
`BaseLayout.noindex`. `/affiliates` added to `NOINDEX_PATHNAMES` in
`astro.config.ts` (excluded from sitemap for both en and zh-CN locale
prefixes via the existing `LOCALE_PREFIXES.flatMap` pattern) and to
`robots.txt Disallow` under every UA block including the explicit AI-bot
overrides (GPTBot, ClaudeBot, OAI-SearchBot, ChatGPT-User, Claude-User,
Claude-SearchBot, PerplexityBot, Google-Extended).
- **BrandButton** — Added `rel?: string` prop so external CTAs across
the site can pair `target="_blank"` with `rel="noopener noreferrer"`.
- **Routes** — Added `affiliates`, `affiliateTerms`,
`affiliateApplicationForm` to `src/config/routes.ts`.
## Component-mapping (per AGENTS.md "no speculative variants" rule)
| Section | Where it lives | Reuse decision |
|---|---|---|
| Hero (split text+media) | `components/affiliates/HeroSection.vue` |
Inline. Existing `HeroSection`s are tightly coupled to specific i18n
namespaces (`cloud.hero.*` etc.) and `legal/HeroSection` is title-only.
|
| Trust band | `components/affiliates/TrustBandSection.vue` | Inline.
`common/SocialProofBarSection` hardcodes a 12-logo client strip; not a
fit for a single text claim. |
| How-it-works | `components/affiliates/HowItWorksSection.vue` +
`common/SectionHeader` | Inline cards. Existing `StepsSection`s are
tightly bound to product-specific namespaces. |
| Who we're looking for | `components/affiliates/AudienceSection.vue` +
`common/SectionHeader` | Inline icon-bullet list.
`pricing/PricingPlanFeatureList` is shaped for plan features with
descriptions. |
| Program details | `components/affiliates/ProgramDetailsSection.vue` +
`common/SectionHeader` | Inline `<table>` (desktop) + `<dl>` (mobile).
`product/shared/ReasonSection` is a long-form "left heading + right
list" layout, not a key/value table. |
| Brand assets | `components/affiliates/BrandAssetsSection.vue` +
`common/SectionHeader` | Inline grid (no existing download-grid
primitive). |
| FAQ | `common/FAQSection.vue` (verbatim reuse) | Reuse — the component
is already generic over `headingKey`/`faqPrefix`/`faqCount`. |
| Footer CTA | `components/affiliates/FooterCtaSection.vue` +
`common/BrandButton` | Inline. `customers/WhatsNextSection` is an
arrow-CTA card, not a centered band. |
## Responsive behaviour
- Hero stacks (text above media) under `lg` (1024px).
- Program Details collapses from `<table>` (md+) to a `<dl>` definition
list (sm).
- 3-step flow collapses from 3-up grid to vertical stack at `md`.
- Brand-asset grid steps from `lg:grid-cols-4` → `sm:grid-cols-2` →
`grid-cols-1`.
## Tests
- **Vitest unit** (`src/components/affiliates/affiliateLanding.test.ts`)
— asserts i18n key structure: every section prefix exists, sections
render in order, no internal/draft keys leak, every indexed item (hero
highlights, steps, audience items, details rows, FAQs) has an English
translation.
- **Playwright e2e** (`e2e/affiliates.spec.ts`) — desktop+mobile
render/visibility under `@smoke`, plus a non-smoke `desktop
interactions` describe that exercises the Apply Now click (popup + form
URL) and FAQ accordion toggle. Mobile asserts table → definition-list
collapse and no horizontal overflow on every section. FAQPage JSON-LD
presence verified end-to-end.
Local verification: `pnpm typecheck`, `pnpm test:unit`, `pnpm exec
playwright test e2e/affiliates.spec.ts`, `pnpm knip` — all green (40
unit, 11/11 e2e).
## Out of scope (intentional follow-ups)
- zh-CN locale + `/zh-CN/affiliates` route (omitted from `robots.txt`
until the route exists; sitemap exclusion already handles it generically
via `LOCALE_PREFIXES.flatMap`).
- Flipping `noindex` off once copy and assets are finalized.
- Dropping in the four banner SVGs (728×90, 300×250, 160×600, 1200×628)
— config object is wired, just edit
`components/affiliates/brandAssets.ts`.
- Hero video (slot is wired).
- Hooking the Apply Now CTA up to a tracked URL once the affiliate
platform is live.
## Cross-PR dependency
The footer "Read the affiliate program terms" link targets
`/affiliates/terms`, which is added by #11954. Until that PR lands, the
link 404s on this branch's preview deployment; once both merge to main,
the pair is complete.
## Screenshots
Desktop (1280w) render attached.
## Screenshots
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-12002-feat-website-draft-Affiliate-Program-landing-page-at-affiliates-3586d73d365081cc9d78cf7ebe04747d)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Glary-Bot <glary-bot@users.noreply.github.com>
Co-authored-by: Miles Ryan <thedatalife@users.noreply.github.com>
## Summary
Migrate the node-menu action path off the legacy
`app.canvas.selected_nodes` dict onto the canonical
`canvas.selectedItems` set so the Pin and Bypass context-menu options
read their selection state from one source.
## Changes
- **What**: `getSelectedNodes` and `getSelectedNodesShallow` in
`useSelectedLiteGraphItems` now derive from
`canvasStore.canvas?.selectedItems` filtered by `isLGraphNode` — the
same source the Pin label already uses via `useSelectionState`. The
Bypass label (`areAllSelectedNodesInMode`) and all node actions
(pin/collapse/bypass/mute/size/runBranch) now share that canonical
source. Subgraph expansion (`getSelectedNodes` → `collectFromNodes`) and
the no-expansion all-match mode toggle are preserved unchanged. The
accessor returns `[]` when the canvas is unavailable, preserving the
prior null-tolerance.
- **Breaking**: None. `app.canvas.selected_nodes` is untouched (still
maintained by LiteGraph, still read by extensions). For every selection
reachable through normal canvas interaction the two collections hold the
identical top-level node set and order, so behavior is preserved.
## Review Focus
- Resolves the dual-source-of-truth flagged by @DrJKL in #12500
(`useNodeMenuOptions.ts:99`): the Pin label read `selectedItems` while
the Bypass label read `selected_nodes`. Both now read `selectedItems`.
- Follow-up to #12500 (FE-720), which merged into `main`.
- **Scope is source-unification only.** Pre-existing semantic gaps are
left as follow-ups: Pin per-node-flip vs Bypass all-match toggle; Pin
expands subgraph children while Bypass does not; reroute-only selection
still renders no-op Pin/Bypass items.
- The legacy `selected_nodes` dict still has direct readers in the
extension layer — tracked in **FE-896** so the dict can eventually be
retired.
## Testing
Unit-only by design — this is a pure composable-layer source swap with
**no user-visible behavior change** (the node set and ordering are
identical to `selected_nodes` for every canvas-originated selection). An
E2E test would only re-exercise existing Pin/Bypass menu flows that
already pass unchanged. Coverage:
- `useSelectedLiteGraphItems.test.ts`: node accessors source from the
canonical `selectedItems`; a decoy node in the legacy `selected_nodes`
dict is asserted *not* to be read; canvas-unavailable returns `[]`
without throwing; subgraph expansion + all-match toggle preserved.
- `useNodeMenuOptions.test.ts`: the Bypass label derives from
`selectedItems`.
- Red→green: `c0bfc94c0a` adds the canonical-source tests (fail against
the legacy-source base); `f7f7176683` migrates the source (all green).
Linear: FE-891
Summary
Moves posthog.reset(true) off the explicit logout action and onto the
user session-state transition (currentUser truthy → null), so PostHog
identity reset fires on every way a session ends — not just
button-initiated logout. Covers server-side token revocation, account
deletion, and cross-tab sign-out, which previously left the user
anonymous without ever resetting PostHog (the identity bleed this guards
against).
Changes
What: Replaces the trackLogout() hook with onUserLogout(() =>
posthog.reset(true)) in PostHogTelemetryProvider's post-init block, next
to the existing onUserResolved identify call. Removes trackLogout() from
the TelemetryProvider interface, TelemetryRegistry, and
PostHogTelemetryProvider (plus the shouldResetOnInit field), and removes
the call site in useAuthActions.logout()
Why state-driven: onUserLogout is watch(resolvedUserInfo, (user, prev)
=> prev && !user && cb()) — it fires on the truthy → null transition
regardless of how the session ended. Since persistence is
browserLocalPersistence, this catches token revocation, account
deletion, and cross-tab sign-out, none of which route through
useAuthActions
reset(true) still generates a fresh anonymous distinct_id — same
identity-bleed guarantee as the old hook, just triggered by the actual
invariant (session ended) rather than one path to it
Net simplification: the entire trackLogout plumbing goes away, and the
previous intentional-skip special case for reauth is no longer needed
Review Focus
Reauth recovery: createReauthenticationRecovery (useAuthActions.ts ~219)
signs out then immediately re-signs-in the same user. The watcher now
fires reset on the transient null and re-identifies the same user right
after — harmless, nothing happens in between, and the old
intentional-skip is no longer required
Pre-init window: the watcher attaches in the post-init .then(), so a
logout during the posthog-js dynamic-import window isn't caught.
Accepted intentionally — nothing is identified pre-init (identify runs
in the same post-init block), so there's no Person to bleed. The one
behavior dropped vs. the old code is the pre-init eventQueue = [] clear;
this only matters in a logout-then-different-login race inside the
import window, documented inline, and no pre-init hook is re-added
Tests: the 3 trackLogout tests are replaced with watcher-fires tests —
truthy → null triggers reset(true), and the reauth roundtrip
re-identifies the same user
---------
Co-authored-by: Nav Singh <nav@comfy.org>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: nav-tej <36310614+nav-tej@users.noreply.github.com>
Co-authored-by: nav <nav@mac.lan>
Co-authored-by: Steven Tran <steventran@Stevens-MacBook-Air.local>
Replaces sending Mixpanel-style "$set_once" in the USER_AUTH_COMPLETED
event with a PostHog people.set_once (fallback to people.set) call after
PostHog initialization.
Prevents telemetry from initializing / sending network calls in test and
E2E environments (detects import.meta.env.MODE === 'test' or VITE_E2E /
VITE_DISABLE_TELEMETRY), to avoid flaky CI sharded E2E failures.
Keeps event capture behavior and queuing logic intact; user-level
property is now set via PostHog people API instead of event payload.
---------
Co-authored-by: Nav Singh <nav@comfy.org>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Steven Tran <steventran@Stevens-MacBook-Air.local>
Co-authored-by: Benjamin Lu <benjaminlu1107@gmail.com>
## Summary
Resolve the 3 outstanding `pnpm lint` warnings in two test files so the
lint run is clean.
## Changes
- **What**:
-
[src/composables/useLoad3d.test.ts](src/composables/useLoad3d.test.ts):
Extract `vi.mocked(...).mock.calls` chains into a single-line
intermediate. The previous multi-line chain tripped an oxlint
`vitest/hoisted-apis-on-top` false-positive; the rule actually targets
`vi.mock`/`vi.hoisted`/`vi.doMock` but mis-flags split
`vi.mocked(...).mock.calls` expressions. All other call sites in the
same file already use the single-line form.
-
[src/platform/workspace/composables/useWorkspaceBilling.test.ts](src/platform/workspace/composables/useWorkspaceBilling.test.ts):
Drop the `{ ...originalLocation, href: ... }` spread when stubbing
`window.location`. `useWorkspaceBilling` only reads
`window.location.href`, so the spread of a `Location` class instance was
both unnecessary and triggered `typescript-eslint/no-misused-spread`.
## Review Focus
- The oxlint warning on `vi.mocked(...).mock.calls` looks like a rule
bug — confirm the workaround is acceptable rather than suppressing the
rule.
- Confirm there is no test that depends on `window.location` carrying
anything beyond `href` in `useWorkspaceBilling.test.ts` (verified: only
`href` is read in production code and assertions).
Verified locally: `pnpm lint` reports 0 warnings / 0 errors, and both
affected test files pass (121 tests).
---------
Co-authored-by: Amp <amp@ampcode.com>
## Summary
Phase 5 of the dialog migration. Replaces the remaining PrimeVue
`useConfirm` / `<ConfirmDialog>` usage in the main frontend (`src/`)
with the `showConfirmDialog` helper added in Phase 1. Public API of
`useDialogService` / `dialogStore` is unchanged.
Parent:
[FE-571](https://linear.app/comfyorg/issue/FE-571/dialog-system-migration-primevue-reka-ui-parent)
This phase:
[FE-577](https://linear.app/comfyorg/issue/FE-577/phase-5-migrate-confirmdialog-callers-secretspanel)
Predecessors: #11719 (Phase 0, merged), #12041 (Phase 1, merged), #12109
(Phase 2, merged), #12182 (Phase 3, merged), #12403 (Phase 4, **stacked
PR base**)
> **Stacked on Phase 4**: this PR targets
`jaewon/fe-576-dialog-reka-migration-phase-4`. Rebase onto `main` after
#12403 lands.
## Changes
### before
<img width="1586" height="840" alt="phase4-before-primevue-confirm"
src="https://github.com/user-attachments/assets/2cb78cc2-7324-4349-b44b-98b5e696a83f"
/>
### after
<img width="1586" height="840" alt="phase5-after-reka-confirm"
src="https://github.com/user-attachments/assets/c092b026-828b-46aa-a4ff-f8611906f692"
/>
### `src/platform/secrets/components/SecretsPanel.vue`
Delete-secret confirmation routes through the Reka helper:
| Before | After |
| --- | --- |
| `useConfirm()` + `<ConfirmDialog group="secrets" />` +
`confirm.require({ acceptClass: 'p-button-danger', accept: () =>
deleteSecret(secret) })` | `showConfirmDialog({ headerProps,
props.promptText, footerProps: { confirmText: t('g.delete'),
confirmVariant: 'destructive', onCancel, onConfirm } })` with explicit
`dialogStore.closeDialog(dialog)` on both branches |
Header / message i18n keys (`secrets.deleteConfirmTitle`,
`secrets.deleteConfirmMessage`) unchanged. Confirm button now uses
`t('g.delete')` instead of the implicit PrimeVue "Yes" default, matching
the Reka helper convention used in `KeybindingPanel` / `AssetCard`.
### `src/components/sidebar/tabs/BaseWorkflowsSidebarTab.vue`
Drops the vestigial `<ConfirmDialog />` mount and its import. The script
section never called `useConfirm()` — close/delete workflow flows were
already migrated to `dialogService.confirm()` (the Reka path) in Phase
1, so the dangling overlay served no consumer.
### Tests
- `src/platform/secrets/components/SecretsPanel.test.ts` **(new)** — 3
tests: helper invoked with destructive variant + correct i18n props,
`onConfirm` closes the dialog **with the exact helper handle** and calls
`deleteSecret`, `onCancel` closes with the handle without deleting. The
mock returns a stable `DIALOG_HANDLE` so a regression that passes the
wrong arg to `closeDialog` fails the suite.
- `src/components/sidebar/tabs/BaseWorkflowsSidebarTab.test.ts` —
removed the now-orphan `vi.mock('primevue/confirmdialog', ...)`.
## Verification
After this PR, the only remaining references to PrimeVue's confirm
system in `src/` are the global `ConfirmationService` registration in
`main.ts`, which is owned by Phase 6 (FE-578) alongside the broader
Dialog / CSS cleanup:
```
$ grep -rn 'primevue/useconfirm\|primevue/confirmdialog\|useConfirm\b' src --include='*.ts' --include='*.vue'
(no matches)
```
## Out of scope
**Phase 6 (FE-578) — main frontend cleanup**
- Remove `ConfirmationService` registration from `src/main.ts`.
- Remove PrimeVue `Dialog` imports from `GlobalDialog.vue` and its
remaining `<style>` overrides (including `.manager-dialog`).
**`apps/desktop-ui/` — not part of FE-577**
- `apps/desktop-ui/src/components/maintenance/TaskListPanel.vue` still
uses `useConfirm()` + `<ConfirmPopup />`, and
`apps/desktop-ui/src/main.ts` + `.storybook/preview.ts` still register
`ConfirmationService`. The desktop app is a separate workspace package
consuming the main frontend; its PrimeVue confirm usage is intentionally
**not** migrated here. Tracking separately (follow-up ticket).
**Renderer scope caveat**
- `showConfirmDialog()` does not currently pass `renderer: 'reka'` to
`dialogStore.showDialog`. The helper continues to render through the
PrimeVue branch in `GlobalDialog.vue` until the helper itself is flipped
(Phase 1/6 territory). This PR only routes callers **to** the helper —
flipping the helper's render path is intentionally out of scope.
## Quality gates
- [x] `pnpm typecheck` — clean
- [x] `pnpm lint` — 0 errors (3 pre-existing warnings in unrelated
files: `useLoad3d.test.ts`, `useWorkspaceBilling.test.ts`)
- [x] `pnpm format` — applied
- [x] `pnpm test:unit` (touched + adjacent):
- `SecretsPanel.test.ts` — 3/3 (hardened to assert handle pass-through)
- `BaseWorkflowsSidebarTab.test.ts` — 3/3
- `src/platform/secrets` + `src/components/sidebar/tabs` +
`src/components/dialog` — 178/178
- [x] Manual verification on `cloud.comfy.org` via local HTTPS dev
server (Settings → Secrets → delete flow, before & after side-by-side)
- [ ] CI Playwright matrix
## Public API impact
None. `useDialogService` / `dialogStore` surface is unchanged.
## Review focus
1. **Destructive variant choice** — `acceptClass: 'p-button-danger'`
(PrimeVue) → `confirmVariant: 'destructive'` (Reka helper). Same
red-affirmative semantic; visual match confirmed in screenshots above.
2. **Confirm label** — switched from PrimeVue's implicit "Yes" to
`t('g.delete')` for the delete flow, matching how `KeybindingPanel` /
`AssetCard` configure the helper.
3. **`BaseWorkflowsSidebarTab.vue` deletion** — verifying the
`<ConfirmDialog />` was genuinely vestigial: `grep useConfirm
src/components/sidebar/tabs/BaseWorkflowsSidebarTab.vue` returns
nothing, and `workflowService.deleteWorkflow` / `closeWorkflow` route
through `dialogService.confirm()` (Reka path).
4. **desktop-ui scope** — see "Out of scope" above. If the team wants
desktop-ui folded into this phase, happy to extend the PR.
---------
Co-authored-by: github-actions <github-actions@github.com>
Co-authored-by: GitHub Action <action@github.com>
## Summary
Add the ECS pattern survey appendix to ADR 0008's companion-documents
table, and drop stale `PromotionStore` references across architecture
docs to reflect the ADR 0009 removal.
## Changes
- **What**:
- New `docs/architecture/appendix-ecs-pattern-survey.md` — surveys
bitECS, miniplex, koota, ECSY, Bevy, and Thyseus: patterns adopted,
departed from, and when to revisit.
- ADR 0008 companion table gains a row pointing at the new appendix.
- `docs/adr/0009-…/before-after-flows.md`,
`docs/architecture/ecs-target-architecture.md`,
`docs/architecture/entity-problems.md` — drop references to
`PromotionStore` / `usePromotionStore` (the legacy three-layer mechanism
is gone; promoted value widgets are now linked `SubgraphInput`s).
- `docs/architecture/subgraph-boundaries-and-promotion.md` — reframes
its "current mechanism" section as historical context with an explicit
"removed by ADR 0009" callout.
- **Breaking**: None — docs-only.
## Review Focus
Wording in the historical-context callout on
`subgraph-boundaries-and-promotion.md`. Everything else is a small
cleanup or a new standalone document.
---------
Co-authored-by: Amp <amp@ampcode.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: GitHub Action <action@github.com>
*PR Created by the Glary-Bot Agent*
---
Draft, `noindex`-gated legal page rendering the **Comfy.org Affiliate
Program Terms and Conditions** verbatim from the source document. Treats
the copy as legal-final-pending-signoff: lives in i18n translations so
legal/non-engineers can edit text without a code change, the page is
excluded from search engines (`<meta robots noindex>` + `robots.txt` +
sitemap filter), and a follow-up PR will flip it to indexable once legal
signs off.
## What this adds
- **Route:** `/affiliates/terms` (en) + `/zh-CN/affiliates/terms`
(zh-CN), matching the existing privacy-policy / terms-of-service
localization pattern.
- **Anchor IDs match the spec exactly:** `#1-program-overview`,
`#2-eligible-products`, …, `#11-miscellaneous` — stable deep-linking.
- **Sticky desktop TOC** with active-section highlighting
(IntersectionObserver, smooth scroll, header offset,
`prefers-reduced-motion` aware).
- **Collapsed `<details>` accordion TOC on mobile** that auto-closes
after a click.
- **Effective Date** is a single i18n key
(`affiliate-terms.effective-date`) — currently `[TBD]`. One config var,
consumed by the page footer.
- **Plain accessible legal-doc styling:** site design tokens, no
marketing flourish or gradients, narrow column for readable line length,
high-contrast text.
- **noindex everywhere:** robots `noindex,nofollow` meta via
`BaseLayout.noindex`, `Disallow: /affiliates/terms` added to every UA
block in `robots.txt` (including the AI-bot overrides), and the route
excluded from `@astrojs/sitemap` for both locales.
## Implementation notes
The website does not currently use MDX — it uses i18n translation keys +
Vue `ContentSection` components for legal pages. I followed that
established pattern (per AGENTS.md "Align with rest of subrepo on impl
and design") rather than introducing MDX integration just for this page.
Editing affiliates terms copy is a one-file change in
`src/i18n/translations.ts`, no code touch required, which satisfies the
"Nav or legal can edit without a code change" intent.
A new component `LegalContentSection.vue` is added (rather than reusing
`ContentSection.vue` directly) because legal docs need: (a) a
`<details>` mobile accordion TOC instead of the existing
horizontal-scroll `CategoryNav`, (b) a footer Effective Date, and (c) a
tighter block-type set (paragraph + bullet list only). Privacy /
Terms-of-Service pages are untouched.
## Skipped per spec
Per the original brief, "Competitive analysis" bullets and the "Open
questions for legal review" callout are internal-only and were not
copied into the i18n keys. There is a unit test asserting no key
matching `competitive-analysis|open-questions|legal-review` exists under
the `affiliate-terms.*` namespace.
## ⚠️ Flag for legal review
The source legal copy contains an internal contradiction that I copied
verbatim rather than silently editing:
- **Section 3 (Commission Structure)** says: *"Commission duration: 3
months from the referred customer's first paid subscription"*
- **Section 7 (Termination)** says: *"Commissions on referred customers
will cease at the time of termination, even if within the **12-month**
commission window"*
These two clauses imply different commission windows (3 months vs 12
months). I left the copy as-is for legal to resolve before the indexable
follow-up PR — flagging here so it doesn't get missed.
## Verification
- `pnpm typecheck` (root) — clean
- `pnpm typecheck:website` — clean (91 Astro files, 0 errors)
- `pnpm test:unit` (website) — 35/35 passing including 5 new unit tests
for the affiliate-terms section structure
- `pnpm exec playwright test affiliates-terms` — 8/8 passing (5 desktop
`@smoke`, 3 mobile `@mobile`)
- `pnpm format:check` — clean
- `pnpm build` — clean, both routes generated, sitemap correctly
excludes both locale variants
- All pre-commit hooks pass (stylelint + oxfmt + oxlint + eslint +
typecheck + typecheck:website + check-unused-i18n-keys)
## Manual verification
Screenshots embedded below from the local Astro preview build at desktop
(1280×900) and mobile (Pixel 5 / 393×852) viewports. The mobile
accordion's collapsed and expanded states are both captured.
## Sub-agent review
Ran the Oracle review against `main`. Initial pass flagged the
Last-updated/Effective-Date footer duplication and a missing zh-CN route
— both addressed in commit `8a1ce890d`. The 3-month vs 12-month
contradiction is left for legal (see above).
## Preview URL
The Vercel preview URL with the route appended will be posted as a PR
comment after CI completes:
`<vercel-preview-host>/affiliates/terms`
## Screenshots
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-11954-feat-draft-Affiliate-Program-Terms-page-at-affiliates-terms-3576d73d36508121851ef666a8c4c537)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Glary-Bot <glary-bot@users.noreply.github.com>
Co-authored-by: glary-bot <glary-bot@comfy.org>
## Summary
Move the canonical `UUID` utilities and the `NodeId` alias up out of
`src/lib/litegraph/` so non-litegraph code can reference them without
crossing the litegraph layer boundary.
## Changes
- **What**:
- `src/lib/litegraph/src/utils/uuid.ts` → `src/utils/uuid.ts` (full
file: `UUID`, `zeroUuid`, `createUuidv4`).
- `NodeId` moves from `src/lib/litegraph/src/LGraphNode.ts` to
`src/world/entityIds.ts`. `LGraphNode.ts` re-exports it; the litegraph
barrel still re-exports `createUuidv4` / `UUID` so the package's public
surface is unchanged.
- All 22 importers updated to `@/utils/uuid` (both
`@/lib/litegraph/src/utils/uuid` and the litegraph-internal
`./utils/uuid` relative paths).
- Drops the two `import-x/no-restricted-paths` ESLint disables in
`src/world/entityIds.ts` that were waiting on these moves.
- **Breaking**: None — litegraph re-exports preserve backward
compatibility for downstream consumers.
## Review Focus
- Each importer's change is identical (`@/lib/litegraph/src/utils/uuid`
→ `@/utils/uuid`), generated by `sed`.
- `src/lib/litegraph/src/LGraphNode.ts` now does `import type { NodeId }
from '@/world/entityIds'` + `export type { NodeId }` — confirm this
satisfies the litegraph layer boundary rules.
- `src/world/entityIds.ts` defines `NodeId` locally as `number |
string`; no semantic change.
Co-authored-by: Amp <amp@ampcode.com>
## Summary
Right-clicking a bypassed node showed two bypass-related items in the
Vue "More Options" context menu (FE-720):
- Plain `Bypass` from the legacy LiteGraph `getExtraMenuOptions` hook in
`litegraphService.ts`
- `Remove Bypass` (with `Ctrl+B` and an icon) from the Vue
`getBypassOption` composable
The Vue menu's exact-label deduplicator in `contextMenuConverter.ts`
collapsed the unbypassed case (both emit `Bypass` → Vue source wins) but
not the bypassed case (`Bypass` vs `Remove Bypass`), so the duplicate
leaked through whenever the node was bypassed.
### before
<img width="1920" height="958" alt="fe-720-before"
src="https://github.com/user-attachments/assets/ef001aca-d70e-4798-ac61-01cc34c31e44"
/>
### after
<img width="1920" height="958" alt="fe-720-after"
src="https://github.com/user-attachments/assets/d6d2bf4b-cb98-4b30-9dac-9bd4b68a7e36"
/>
#### single active node (KSampler)
<img width="1920" height="958" alt="fe-720-1-unbypassed-node-menu"
src="https://github.com/user-attachments/assets/bec9cd47-2f2d-4adb-b95b-266e7969a36c"
/>
#### single bypassed node (Load Checkpoint)
<img width="1920" height="958" alt="fe-720-2-bypassed-node-menu"
src="https://github.com/user-attachments/assets/91f80157-836d-4fce-adad-474f31baff04"
/>
#### KSampler + bypassed Load Checkpoint
<img width="1920" height="958" alt="fe-720-3-mixed-selection-menu"
src="https://github.com/user-attachments/assets/e4780b16-08e5-4f87-80e9-3ff65a5acdae"
/>
## Root cause
`src/services/litegraphService.ts` pushes a `Bypass` entry from its
legacy `getExtraMenuOptions` hook in addition to the Vue
`getBypassOption`. In Vue-menu mode both reach the menu; the exact-label
dedup in `contextMenuConverter.ts` only collapses them when the labels
match, which fails once the node is bypassed and the Vue side switches
to `Remove Bypass`.
## Fix
Add `Bypass` and `Remove Bypass` to the `HARD_BLACKLIST` in
`contextMenuConverter.ts`. The blacklist filters the legacy emission out
of the Vue conversion pipeline (`convertContextMenuToOptions`) before it
is ever merged, so Vue's `getBypassOption` is the single source of the
bypass item in every node state — no duplicate is created in the first
place. This is the established convention for legacy items that the Vue
menu replaces (`Properties`, `Colors`, `Shapes`, `Title`, `Mode`,
`Properties Panel`, `Copy (Clipspace)`); Bypass is the same category.
`litegraphService.ts` reverts to a plain `content: 'Bypass'` and no
longer imports `areAllSelectedNodesInMode` or i18n keys for this entry.
The Vue `getBypassOption` label is still derived from the same
selection-aware predicate (`areAllSelectedNodesInMode`) that
`toggleSelectedNodesMode` uses, so on mixed selections the label stays
in sync with the action — it shows `Bypass` when clicking would bypass
the rest, rather than `Remove Bypass`.
**Trade-off:** the classic LiteGraph canvas menu
(`Comfy.VueNodes.Enabled: false`) renders `litegraphService`'s options
directly without going through `convertContextMenuToOptions`, so it
shows a plain `Bypass` regardless of node state. This matches the pre-PR
behavior (the legacy push was already a hardcoded `Bypass`), so it is
not a regression.
## Considered and rejected
- **`equivalents` map** (`bypass: ['bypass', 'remove bypass']`) — would
collapse `Bypass` and `Remove Bypass` as synonyms, which is semantically
wrong: they are distinct actions that must stay distinguishable, and the
rule would also misfire on the unbypassed case. A converter test locks
in that they are not treated as equivalents.
- **State-aware label on the legacy push** (matching the Vue label so
the exact-label dedup collapses them) — works, and additionally gives
the classic canvas menu a state-aware label, but it couples
`litegraphService` to the selection predicate and i18n keys solely to
keep a downstream dedup load-bearing. `HARD_BLACKLIST` removes the
duplicate at the source instead of creating, converting, then collapsing
it. The only thing lost is the classic-menu state-aware label, which was
never present pre-PR.
- **Gating the legacy push on `Comfy.UseNewMenu === 'Disabled'`** — the
setting that selects the legacy vs Vue context menu is
`Comfy.VueNodes.Enabled`, not `Comfy.UseNewMenu` (an unrelated
top-menu-bar toggle). Gating on `UseNewMenu` would drop the Bypass entry
from the legacy canvas menu for the OSS default (`VueNodes.Enabled:
false` + `UseNewMenu: 'Top'`).
- **Suppressing the legacy callback via
`SUPPRESSED_LITEGRAPH_CALLBACKS`** — matches by callback identity and
adds cross-file coupling for what is a simple label-based filter that
`HARD_BLACKLIST` already expresses.
## Cleanups (review feedback)
- Removed the now-dead `NodeSelectionState.bypassed` field and its
producer (no consumers after the label switch).
- Replaced the `vue-i18n` mock in `useNodeMenuOptions.test.ts` with a
real `createI18n` instance per `docs/testing/vitest-patterns.md`;
removed a `ts-expect-error` via a typed hoisted `app` mock.
- Simplified `getSelectedNodeArray` to
`Object.values(app.canvas.selected_nodes ?? {})`.
## Tests
- `useSelectedLiteGraphItems.test.ts` — `areAllSelectedNodesInMode`:
all-bypassed → true, mixed → false, empty → false.
- `useNodeMenuOptions.test.ts` — Vue label is `Bypass` (active / mixed)
and `Remove Bypass` (all bypassed).
- `contextMenuConverter.test.ts` — the legacy `Bypass` push is filtered
by `HARD_BLACKLIST` so the Vue item is the only bypass entry (keeps
shortcut/source); `Bypass` and `Remove Bypass` are not treated as label
equivalents.
- `browser_tests/tests/vueNodes/interactions/node/contextMenu.spec.ts` —
e2e regression: exactly one bypass-family item per node state.
Verified live on a bypassed Load Checkpoint: single `Remove Bypass` →
toggle un-bypasses → single `Bypass`; no duplicate, rest of the menu
intact.
- Fixes FE-720
---------
Co-authored-by: Alexander Brown <drjkl@comfy.org>
When converting to subgraph, `beforeChange` and `afterChange` were being
called, but these functions exclusively called vestigial change handlers
that don't actually affect change tracking.
Consequentially, if you made a change to the graph (updating a widget),
converted a node to a subgraph using the selectionToolbox, and then
pushed Ctrl+Z before performing any other canvas interaction, it would
incorrectly undo the prior widget edit as well.
This is resolved by calling the important handlers directly. Adding them
to `beforeChange`/`afterChange` was considered, but caused breakage in
other functions (`connect`) which failed to even attempt symmetric calls
of the function.
## Summary
Silence false Iconify warning spam during Tailwind lint analysis while
preserving icon utility generation and real failure signals.
## Changes
- **What**: Local wrapper around `@iconify/tailwind4` that swallows the
noise from `better-tailwindcss/enforce-canonical-classes` probes.
Wrapper delegates icon resolution to upstream's `getDynamicCSSRules`;
only custom-comfy folder loading is reimplemented. `lucideStrokePlugin`
uses a `InvalidIconProbeError` sentinel so missing icons / missing deps
still surface.
- **Dependencies**: None.
## Background
Both upstreams have refused to address this:
- `better-tailwindcss`
([schoero/eslint-plugin-better-tailwindcss#377](https://github.com/schoero/eslint-plugin-better-tailwindcss/issues/377),
open) — owner declines to filter third-party warnings; says it should be
fixed in iconify.
- `@iconify/tailwind4`
([iconify/iconify#357](https://github.com/iconify/iconify/issues/357),
closed) — maintainer defends the `console.warn` as intentional; *"not
something plugin has control over"*.
Trigger path: `enforce-canonical-classes` → Tailwind
`canonicalizeCandidates()` → iconify `matchComponents` handler throws on
non-icon strings → upstream catches + `console.warn`.
## Review Focus
- Inline `loadComfyIconSet` in `iconifyDynamicPlugin.js` skips
`@iconify/tools`' `parseColors → currentColor` normalization. Verified
the comfy SVGs already use `currentColor` directly; multi-color icons
(bria, bytedance) keep their explicit fills as expected.
- `lucideStrokePlugin.js` catch is now type-discriminated — only
`InvalidIconProbeError` returns `{}`; `Cannot load icon set` and `Cannot
find icon` re-throw.
---------
Co-authored-by: Amp <amp@ampcode.com>
## Problem
When a user is **already signed in** and a client (e.g. an MCP client)
starts the OAuth flow, the consent screen fails with:
> OAuth request failed. Please restart from the client app.
**Repro:** be signed in to Cloud, then trigger an OAuth authorization
from a client. Instead of the consent screen, the consent view renders
the generic error.
## Root cause
The consent challenge request (`GET /oauth/authorize`) is authenticated
by the Cloud **session cookie** — a distinct credential from the
Firebase client login that `isLoggedIn` reflects.
- The **post-login** resume path (`useOAuthPostLoginRedirect`) mints
that cookie via `createSessionOrThrow()` before navigating to consent.
- The **already-signed-in** path — the `cloud-login` / `cloud-signup`
`beforeEnter` guards in `onboardingCloudRoutes.ts`, which short-circuit
straight to consent when `isLoggedIn` is `true` — skipped that step.
With no session cookie the consent challenge request is unauthenticated,
so the server redirects it to login; `fetch` follows the redirect to an
HTML page, `response.json()` throws, and `OAuthConsentView` falls
through to `genericError`.
The `Comfy.Cloud.SessionCookie` extension's `createSession()` on
auth-resolve is fire-and-forget and races the redirect, so it doesn't
reliably cover this path.
## Fix
`oauthConsentRedirect()` now mints the session cookie
(`createSessionOrThrow()`) before redirecting an already-signed-in user
to consent — symmetric with the post-login path. Best-effort: on failure
it logs and still lands on the consent view so the user gets an
actionable message rather than a silently dropped flow.
## Test plan
- [x] New `onboardingCloudRoutes.test.ts`: resume → mints cookie then
routes to consent; no pending OAuth → `cloud-user-check` (no mint); mint
failure → still routes to consent so the view surfaces the error.
- [x] `vue-tsc` typecheck, eslint, oxlint clean.
- [ ] Manual: already signed in to Cloud, start OAuth from a client →
consent screen renders (no "OAuth request failed").
## Summary
Stamp App Mode telemetry with the properties needed to measure the App
Builder product metrics validly in PostHog. Three small, independent
enrichments on top of the App-Mode execution attribution.
## Changes
- **What**:
- `view_mode` on `execution_start` / `execution_success` /
`execution_error` (captured at queue time alongside `is_app_mode`). Lets
the North Star be `execution_success` where `view_mode='app'` — genuine
app runs, excluding `builder:arrange` builder-preview runs that bare
`is_app_mode` also counts.
- `workflow_id` on `app:workflow_saved` and `app:app_mode_opened`
(sources `workflow` / `template_url`) via a shared
`workflowTelemetryId()` helper; `storeJob` refactored onto it so save /
open / run events share one join key. Enables distinct-app counts,
activated apps (created → ≥1 successful run), and per-app quality.
- intrinsic `is_app` on `app:share_flow` `link_created` (from the
workflow's `initialMode`, not the share-time view) plus `workflow_id`;
`is_app` on `app:workflow_imported` / `opened` (from the loaded graph's
`extra.linearMode`). Enables virality by true app-ness and app-traffic
attribution.
- **Breaking**: none.
- **Dependencies**: none.
## Review Focus
- **The commits to review are the three after the foundation**:
`view_mode`, `workflow_id`, and `is_app`. The first commit in the diff
(`feat: attribute workflow executions to App Mode in telemetry`) is the
pre-existing foundation this builds on — its branch is not currently on
the remote, so this PR is based on `main` and carries it forward.
Reviewing per-commit is easiest.
- **Join-key consistency**: `workflowTelemetryId()` is the single
definition of the workflow id (`activeState.id ?? initialState.id`),
shared by the new save/open events and the existing execution events. A
divergence would silently break the created→run and opened→run joins.
Unit-tested.
- **Scope (YAGNI)**: `workflow_id` / `is_app` added only where a locked
metric consumes it — `share_flow` only on `link_created`;
`app_mode_opened` only on the `workflow` / `template_url` sources (not
`app_builder` / `keybind`).
- **No double serialize**: `app.ts` reuses a single
`rootGraph.serialize()` for both the `is_app` derivation and
`afterLoadNewGraph`.
Cloud-only (telemetry is tree-shaken from OSS builds). No UI changes.
---------
Co-authored-by: AustinMroz <austin@comfy.org>
Co-authored-by: GitHub Action <action@github.com>
## Summary
Responsive polish: stack mobile pricing plans, rework the cloud product
hero so the illustration and text fit at all viewports, shrink the local
product hero illustration below xl, and reduce the cloud banner font
size on mobile.
## Changes
- **What**:
- `pricing/PriceSection.vue`: replace mobile tab-toggle pattern with
stacked plan cards; drop the `activePlanIndex` ref and tab buttons.
- `product/cloud/HeroSection.vue`: rework layout so illustration and
text fit across breakpoints (md/lg sizing, spacing, max-widths).
- `product/local/HeroSection.vue`: shrink illustration container below
xl (`max-w-xs`/`md:max-w-sm`/`lg:max-w-md`).
- `product/shared/CloudBannerSection.vue`: smaller font on mobile
(`text-sm` instead of `text-lg`).
## Review Focus
- Mobile pricing UX: confirm stacked cards are preferable to the prior
tab-toggle for our target viewports.
- Cloud hero layout at md/lg/xl breakpoints — check for overflow or
awkward spacing.
## Screenshots (if applicable)
<!-- Add before/after screenshots of the pricing page (mobile) and
product hero pages. -->
---------
Co-authored-by: github-actions <github-actions@github.com>
## Summary
Hardens PostHog initialization in the cloud app and website with three
missing config options identified during PostHog QA audit.
## Changes
- **What**: Adds `person_profiles: 'identified_only'`, `cookie_domain:
'.comfy.org'`, and `before_send` PII redaction hook to both PostHog init
calls
- **person_profiles**: Prevents anonymous Person records being created
in PostHog for pre-auth visitors — only creates Person after
`identify()` is called (matches website config which already had this)
- **cookie_domain**: Enables cross-subdomain session stitching across
`app.comfy.org`, `docs.comfy.org`, `www.comfy.org` — without this, each
subdomain creates a separate PostHog session
- **before_send**: Last-line PII guard — strips `email`, `prompt`,
`user_email`, `$email` from event properties before transmission. Placed
after `...serverConfig` spread so it cannot be overridden by remote
config.
## Review Focus
- `before_send` runs before GeoIP enrichment — deliberately does NOT
drop `$ip` since country-code targeting needs it for the pricing
experiment
- `person_profiles: 'identified_only'` + anonymous flag evaluation:
PostHog confirmed this still allows flag eval via `$anon_distinct_id`;
stitched retroactively on `identify()`
- `serverConfig` spread is before the three new fields — these take
precedence over any remote config values (intentional for
security/correctness)
Closes MAR-233, MAR-235, MAR-236
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Miles <miles@comfy.org>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: nav <nav@mac.lan>
Co-authored-by: Miles Ryan <thedatalife@users.noreply.github.com>
## Summary
Upgrades the website app from Astro 5.10 to Astro 6.4.2.
## Changes
- **What**: Bumps `astro` (5.10 → 6.4.2), `@astrojs/vue` (5 → 6.0.1),
`@astrojs/sitemap` (3.7.1 → 3.7.3), and `@astrojs/check` (0.9.8 → 0.9.9)
in the workspace catalog. Refreshes `vite` in the lockfile from `8.0.0`
to `8.0.14` to clear a Vite/Rolldown "Not implemented" regression in dep
optimization that Astro v6 triggered on `8.0.0`.
- **Breaking**: None for our code. Audit against the [Astro v6 upgrade
guide](https://docs.astro.build/en/guides/upgrade-to/v6/) found no
breaking change applies:
- Already on `<ClientRouter />` (no removed `<ViewTransitions />`)
- No content collections (`defineCollection`/`getCollection`) — legacy
removal n/a
- `getStaticPaths` functions don't access the deprecated `Astro` global
- No `<Image>`/`<Picture>`/`getImage()` usage — SVG rasterization &
client-throw n/a
- No `import.meta.env.ASSETS_PREFIX`
- No file-extension endpoints (`*.xml.ts`/`*.json.ts`) so the
trailing-slash change is moot
- No markdown content (heading-ID compat n/a)
- i18n config (`prefixDefaultLocale: false`, no
`redirectToDefaultLocale`) is compatible with the new
`redirectToDefaultLocale: false` default
- No experimental flags enabled
## Review Focus
- The Vite lockfile bump from 8.0.0 → 8.0.14 inside the same `^8.0.0`
range. Without it, `astro check` on v6 hits `Not implemented` inside
Vite's `esbuildPlugin.generateBundle` via Rolldown.
- Sanity-check the audit above against any in-flight work that might add
content collections / `<Image>` etc.
## Verification
- `pnpm typecheck` → 0 errors
- `pnpm build` → 379 pages built
- `pnpm test:unit` → 85/85 passing
- `pnpm lint` → 0 errors (3 pre-existing warnings)
## Summary
cloud.comfy.org (and any route before the graph view mounts, e.g. the
login screen) renders no favicon. Add a static fallback so a favicon
always shows.
## Changes
- **What**: The favicon is only ever set at runtime —
`useFavicon('/assets/favicon.ico')` in `LayoutDefault.vue` and the
progress frames in `useProgressFavicon.ts`. Before that JS runs (first
paint, login screen, routes that don't mount
`GraphView`/`LayoutDefault`), no `<link rel="icon">` exists, and the
browser's default `/favicon.ico` request hits the SPA catch-all and
returns HTML, so no favicon renders. Added a single static `<link
rel="icon" href="/assets/favicon.ico">` (asset already exists) to
`index.html`.
- **Breaking**: none.
## Review Focus
- Single icon link is intentional: vueuse `useFavicon` overwrites the
`href` of every `link[rel*="icon"]` at runtime (including
`apple-touch-icon`), so the progress-favicon animation assumes one
controllable icon link. Adding multiple static links (svg/png) would get
their `href` clobbered to the progress PNG mid-generation and render
inconsistently — so this PR deliberately adds just the `.ico`.
- The progress-favicon still works: vueuse updates this same link's
`href`.
- Path matches what the app already uses at runtime
(`/assets/favicon.ico`).
## Screenshots (if applicable)
## Summary
Narrow Knip's Playwright `entry` to actual spec files so dead exports in
browser-test fixtures are reported instead of being hidden by treating
every helper as an entrypoint.
## Changes
- **What**:
- `knip.config.ts`: Playwright `entry` changed from the broad
`['**/*.@(spec|test)…', 'browser_tests/**/*.ts']` to
`['browser_tests/**/*.@(spec|test).?(c|m)[jt]s?(x)']`.
`globalSetup`/`globalTeardown` stay covered via Knip's playwright config
resolution; fixtures remain in the project graph so their unused exports
surface.
- Resolved the 54 dead findings this exposed: over-exported symbols used
only within their own module are now module-private (dropped `export`,
no behavioral change); genuinely unreferenced fixtures were deleted
(asset/template `ALL_*` aggregators + orphaned `STABLE_*` data,
`TemplateHelper` distribution helpers + `generateTemplates`, dead
types/utils, and the unused `nodeDefinitions.ts` module).
- **Breaking**: none — test-only changes.
## Review Focus
- Deletions are limited to fixtures with zero importers on `main`
(verified via `pnpm knip`); the bulk of the diff is `export`-keyword
removal.
- Verified: `pnpm knip` (browser_tests clean), `pnpm typecheck`, `pnpm
typecheck:browser`, oxfmt/oxlint/eslint all pass.
Linear: FE-717
## Summary
The "Open shared workflow" dialog rendered the workflow name in an
`<h2>` with no
wrapping control. A long, space-free name (e.g. a content-hash filename)
is a
single unbreakable "word", so with the default `overflow-wrap: normal`
it could
not wrap. It overflowed its box and, because PrimeVue's
`.p-dialog-content` is
`overflow-x: auto`, the dialog scrolled horizontally instead of
wrapping.
CDP measurement on the unfixed build (96-char name): dialog content
`scrollWidth 1336` vs `clientWidth 702` -> horizontal scroll. After
adding
`wrap-anywhere` to the heading: `scrollWidth 702 == clientWidth 702`,
name wraps
to multiple lines, full name still in the DOM.
### before
<img width="704" height="295" alt="before-dialog"
src="https://github.com/user-attachments/assets/ea05ab32-a80d-4210-951c-f43d595bd6eb"
/>
### after
<img width="704" height="359" alt="after-dialog"
src="https://github.com/user-attachments/assets/cbf3019e-5e71-4dba-a1fd-ea3586dd995a"
/>
## Changes
- `OpenSharedWorkflowDialogContent.vue`: add `wrap-anywhere` to the
workflow-name
`<h2>` so a long unbreakable name wraps within the dialog bounds instead
of
forcing horizontal scroll. The parent already has `min-w-0`.
- Breaking: none
## Red-Green Verification
| Commit | CI | Purpose |
|--------|-----|---------|
| [`test:`
d9158d1](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/26678596015)
| 🔴 Red (failure) | Proves the test catches the bug — cloud
e2e failed at `expect(scrollWidth).toBeLessThanOrEqual(clientWidth +
1)`: received 1332, expected <= 703 |
| [`fix:`
08e75a1](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/26678974321)
| 🟢 Green (success) | Proves the fix resolves it |
Fixes FE-828
## Test Plan
- [x] CI red on test-only commit
- [x] CI green on fix commit
- [x] E2E regression
`browser_tests/tests/dialogs/openSharedWorkflowDialog.spec.ts` (@cloud):
mocks a long-named shared workflow, asserts the dialog does not overflow
horizontally
- [x] Manual CDP verification (before/after above)
## Summary
Fix the comfy.org favicon declaration so Google Search can actually
refresh it — the logo has shown the old Astro starter chevron in Google
results for weeks even though the icon files were fixed in May.
## Changes
- **What**: The site declared two SVG favicons gated by
`prefers-color-scheme` media queries, no PNG favicon, and a
`favicon.ico` with only a 64×64 image. Google Search's favicon pipeline
can't resolve a single valid icon from that, so on recrawl it keeps the
last good cached icon (the old Astro chevron) instead of the current
mark. Replaced with the standard, checker-clean set:
- `favicon.svg` — single adaptive SVG (light/dark swap via internal CSS)
replacing the two media-query SVG links
- `favicon-96x96.png` — explicit desktop PNG at a Google-recommended
size (multiple of 48)
- `favicon.ico` — rebuilt to contain 16/32/48 (was 64×64 only)
- `site.webmanifest` + `web-app-manifest-192x192.png` / `-512x512.png`
- `<head>` simplified to RealFaviconGenerator's recommended markup +
`theme-color`
- **Breaking**: none. Pure static-asset + `<head>` change, no runtime
code touched.
## Review Focus
- This resolves the 3 errors + 3 warnings RealFaviconGenerator reported
for comfy.org (2 SVG favicons / no desktop PNG / ICO missing 16-32-48 /
no web manifest).
- The old `favicon-light.svg` and `favicon-dark.svg` are left in place
(now unreferenced) to avoid deleting assets in this PR — safe to remove
in a follow-up if desired.
- **Post-merge, required to actually fix Search**: in Google Search
Console, run URL Inspection → Request Indexing on `https://comfy.org/`.
The Search favicon only refreshes when Googlebot recrawls the homepage;
without a clean icon set + a recrawl nudge it will not self-correct.
## Before / After
### Before
<img width="939" height="388" alt="image"
src="https://github.com/user-attachments/assets/5fa95fd6-2248-4ed9-921e-9c516f4c0c3e"
/>
### After
<img width="1145" height="447" alt="image"
src="https://github.com/user-attachments/assets/dc33a99d-f7f6-41d4-a83d-03b3b99d0b0d"
/>
## Screenshots (if applicable)
## Summary
`extra.linearData.inputs` validation rejected the entire workflow
whenever a single entry didn't match the strict `z.union([3-tuple,
2-tuple])`, surfacing as `Failed to load shared workflow: invalid
workflow data` for some published cloud shares (e.g.
`share=21e32125c692`).
## Changes
- **What**: Shared workflow load now matches the regular load policy at
`scripts/app.ts:1191-1198` — if Zod validation fails, fall back to the
raw `workflow_json` instead of throwing. Share service no longer runs
schema validation directly; `app.loadGraphData()` continues to validate
and apply the same raw fallback under `Comfy.Validation.Workflows`.
- **Breaking**: None — workflows that previously failed to load through
the share path now load with the same permissive behavior as workflows
opened through any other entry point.
## Review Focus
The original approach added a `tolerantArray` combinator to drop bad
`linearData.inputs` entries inside the schema. After review, the cleaner
direction is to keep schemas strict as the canonical spec and apply
tolerance at the consumer boundary — which `scripts/app.ts:1191-1198`
already does for the regular load path (`graphData = validatedGraphData
?? graphData` with the comment "Ideally we should not block users from
loading the workflow"). This PR aligns the share path with that existing
policy and removes a cross-path inconsistency rather than introducing a
new schema-level concept.
Consequences:
- Schemas in `workflowSchema.ts` stay unchanged (canonical spec).
- The `extra.*` shape drift problem is now solved generally, not just
for `linearData.inputs` — future fields hitting the same class of issue
will load instead of blocking.
- `validateComfyWorkflow` still logs the Zod error via `console.warn`
for debugging.
## Tests
- Existing schema tests stay strict (3-tuple, 2-tuple unions reject bad
shapes).
- New regression test in `workflowShareService.test.ts`: a
`workflow_json` that passes the share response envelope
(`record<unknown>`) but fails `ComfyWorkflowJSON` is returned raw, not
thrown.
### current prod
<img width="1144" height="565" alt="Screenshot 2026-05-13 at 1 29 00 PM"
src="https://github.com/user-attachments/assets/b1abf45b-a588-4ef5-a9ec-d14bd1096b6d"
/>
### test
`/?share=21e32125c692`
<img width="765" height="826" alt="Screenshot 2026-05-13 at 1 27 40 PM"
src="https://github.com/user-attachments/assets/96a3c405-e5fe-4732-9047-fed90768e6f6"
/>
## Follow-up
Structural issue separately: cloud OpenAPI defines `workflow_json` as
opaque `z.record(z.unknown())`
(`packages/ingest-types/src/zod.gen.ts:137,325,375,397,457`), so ingest
schema CI cannot enforce inner shape. Matt Miller is driving the
lift-schema-to-core-OpenAPI direction; tracked separately, not in this
PR.
Fixes FE-690.
## Summary
Removes three security overrides added in #12345/#12501 that are now
no-ops: every consumer in the tree already pulls a version at or above
the GHSA-patched release.
## Changes
- **What**: Drops `brace-expansion@^1.0.0`, `brace-expansion@^2.0.0`,
and `ws@^8.0.0` overrides from
[pnpm-workspace.yaml](pnpm-workspace.yaml).
- **Breaking**: None.
| Override removed | Patched at | Natural resolution | GHSA |
|---|---|---|---|
| `brace-expansion@^1.0.0: ^1.1.13` | 1.1.13 | 1.1.15 |
[GHSA-f886-m6hf-6m8v](https://github.com/advisories/GHSA-f886-m6hf-6m8v)
|
| `brace-expansion@^2.0.0: ^2.0.3` | 2.0.3 | 2.1.1 |
[GHSA-f886-m6hf-6m8v](https://github.com/advisories/GHSA-f886-m6hf-6m8v)
|
| `ws@^8.0.0: ^8.20.1` | 8.20.1 | 8.21.0 |
[GHSA-58qx-3vcg-4xpx](https://github.com/advisories/GHSA-58qx-3vcg-4xpx)
|
The remaining security overrides (`lodash`, `yaml`, `minimatch@^9`,
`minimatch@^10`, `ajv@^8`) were re-tested and are still required —
without them dependabot-vulnerable versions (`lodash@4.17.23`,
`yaml@2.7.1`, `minimatch@9.0.1`, `minimatch@10.2.1`,
`ajv@8.12.0`/`8.13.0`) resolve into the tree.
## Review Focus
- The `brace-expansion@5.x` and `minimatch@5.x`/`8.x` lines in the
lockfile naturally resolve to safe versions (`5.0.6`, `5.1.9`, `8.0.7`)
on `main`, so no new overrides are needed alongside this removal.
- Verified by removing each override one-by-one and inspecting `pnpm why
-r`.
## Verification
- `pnpm install` — clean
- `pnpm typecheck` (apps/website + root) → 0 errors
- `pnpm test:unit` (apps/website) → 89/89 passing
- `pnpm lint` (root) → 0 errors (3 pre-existing warnings)
## Summary
- Add `<br>` after "Built something cool with ComfyUI?" in the gallery
contact heading (en + zh-CN) so the Submit link wraps to a new line.
- Switch the Enterprise product card background from
`bg-illustration-forest` to `bg-secondary-cool-gray`.
## Test plan
- [ ] Visit the gallery contact section and confirm the heading wraps
after "ComfyUI?" in both English and Chinese.
- [ ] Verify the Enterprise card on the product cards section renders
with the cool gray background.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Alexander Brown <drjkl@comfy.org>
## Summary
Establish a single source of truth for gallery items. Previously the
items array and the `GalleryItem` interface lived inline in
`GallerySection.vue`, with three sibling components importing the type
*out of a `.vue` file* — coupling pure data and types to a presentation
component.
- **One canonical list.** Items now live in `src/data/gallery.ts`
alongside the `GalleryItem` interface.
- **Per-item visibility without deletion.** New optional `visible?:
boolean` field on each item
- **Stable identity.** Each item now carries a required `id` kebab-slug
derived from its title.
- **lookup helper.** `getGalleryItemById(id)` for callers that want a
single item.
The sibling gallery components (`GalleryCard`, `GalleryDetailModal`,
`GalleryItemAttribution`) now import the `GalleryItem` type from
`../../data/gallery` instead of from the `.vue` file.
## Scope note
I also audited the rest of the website for other surfaces that should
consume the centralized data.
**I need this refactor for the new page `models` coming soon.**
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: GitHub Action <action@github.com>
## Summary
Preserve validation node errors and their overlay when a valid active
root starts execution, so partial workflow runs no longer hide
validation failures.
## Changes
- **What**: Split execution-start clearing from full error clearing;
`execution_start` now clears transient execution/prompt state without
clearing validation `lastNodeErrors`.
- **What**: Keep the ErrorOverlay open when validation errors are still
present, and show it for successful prompt responses that include
`node_errors`.
- **Dependencies**: None.
## Review Focus
Please check the error-clearing boundary between prompt
submission/workflow changes and WebSocket `execution_start`. Full
clearing still happens through `clearAllErrors`; execution start now
uses the narrower clearing path and only dismisses the overlay when
there are no validation node errors to show.
Linear: FE-851
## Red-Green Verification
- Red: `76bcf34c4 test: add failing validation error preservation e2e`
- Green: `9766172ea fix: preserve validation errors on execution start`
- Follow-up: `321c95aba fix: keep validation error overlay during
execution start`
- Coverage: `7b5fab577 test: cover prompt node error overlay`
## Test Plan
- `pnpm exec vitest run src/scripts/app.test.ts`
- `pnpm exec vitest run src/stores/executionStore.test.ts`
- `pnpm exec vitest run src/scripts/app.test.ts
src/stores/executionStore.test.ts --coverage`
- `pnpm format:check -- src/stores/executionErrorStore.ts
src/stores/executionStore.ts src/stores/executionStore.test.ts
src/scripts/app.ts src/scripts/app.test.ts
browser_tests/fixtures/helpers/ExecutionHelper.ts
browser_tests/tests/execution.spec.ts`
- `pnpm exec oxlint src/stores/executionErrorStore.ts
src/stores/executionStore.ts src/stores/executionStore.test.ts
src/scripts/app.ts src/scripts/app.test.ts
browser_tests/tests/execution.spec.ts --type-aware`
- `pnpm typecheck`
- `PLAYWRIGHT_LOCAL=1 PLAYWRIGHT_TEST_URL=http://127.0.0.1:5175 pnpm
exec playwright test browser_tests/tests/execution.spec.ts:132`
## Screenshots (Before/After)
Before
https://github.com/user-attachments/assets/04a212b6-66f9-4c77-9056-58bdc642d96e
After
https://github.com/user-attachments/assets/db7813c7-bf8a-4e19-9b66-7f49fd01c305
Under some circumstances (Only firefox+FLAC outputs for me, but reliably
reproducible), clicking the play button on audio outputs in the assets
sidebar tab will fail to start playback. This appears to be caused by
unusual interactions between blob urls, `preload="metadata"`, and FLAC
not defining total content length in the header.
Instead of managing the lifecycle of a blob url, the real audio source
is left in place and caching can be done on the browser side.
I put some extensive time into trying to find a regression test that
works on chromium, but did not see results and decided it's better this
be merged without a test than never get fixed.
Context menu operations on subgraph IO slots only set the foreground
canvas as dirty, so links would visually persist until a different
operation caused a background draw.
## Summary
This PR extends the error catalog with targeted runtime error messaging
for common workflow execution failures.
The goal is to show clearer, user-facing copy in the error panel while
preserving the raw API `message` and `details` fields on each error
item. The resolver continues to add display-only fields (`displayTitle`,
`displayMessage`, `displayDetails`, `displayItemLabel`, `toastTitle`,
`toastMessage`) so the UI can render friendlier messages without
changing the underlying error contract.
## What This PR Targets
This PR adds catalog handling for common runtime failure categories,
including:
- General execution failure fallback for uncataloged node runtime errors
- Content blocked / safety check failures
- Credits, subscription, access, and sign-in related failures
- Rate limit and busy-server style failures
- Runtime timeout, stalled generation, and preparation failure cases
- Server stopped / unavailable cases
- Out-of-memory failures
- Image load failures
- Invalid CLIP input failures
- Invalid prompt and invalid workflow request failures
- Request/start/end failure cases
- Model access and model download failures
- Unexpected service failures
Unknown node execution errors resolve to the general runtime fallback:
- Title: `Execution failed`
- Message: `Node threw an error during execution.`
- Item label: node name
- Toast title: `{nodeName} failed`
- Toast message: `This node threw an error during execution. Check its
inputs or try a different configuration.`
## Implementation Notes
### Resolver Split
The previous resolver file was doing too much, so this PR splits
source-specific catalog logic into smaller modules:
- `catalogIds.ts` defines FE-resolved catalog IDs that normalize
multiple sources or do not map 1:1 to an API error type.
- `catalogI18n.ts` owns shared translation/fallback helpers.
- `validationErrorResolver.ts` keeps validation catalog logic.
- `promptErrorResolver.ts` keeps prompt-specific catalog logic and
handles non-node-scoped failures before falling back to prompt-specific
keys.
- `executionErrorResolver.ts` handles node-scoped runtime errors.
- `runtimeErrorMatcher.ts` owns conservative runtime error matching.
- `runtimeErrorCopy.ts` builds runtime display/toast fields from catalog
IDs and fallback copy.
- `missingErrorResolver.ts` keeps the existing missing-model/node/media
group display copy.
`errorMessageResolver.ts` is now a thin facade over these smaller
resolvers.
### Conservative Matching
Runtime errors can share generic exception labels, so this PR keeps
matching narrow: exact strings or stable prefixes only. The matcher is
ordered, and the first matching rule wins, so specific user-actionable
failures are checked before broader fallbacks.
The matching is intentionally not fuzzy. For example, arbitrary messages
that merely mention moderation terminology are not treated as
content-blocked unless they match one of the known client-visible
failure strings. This avoids false positives while covering the targeted
high-volume cases.
### Raw Detail Preservation
Some cataloged errors keep the original message as `displayDetails` when
it contains useful troubleshooting context. This is display-only; the
raw API `message` and `details` fields remain unchanged on the original
error item.
## Out Of Scope / Follow-Ups
This PR does not redesign the error overlay or right-side error panel
UI. It only provides the resolved fields those surfaces can consume.
Planned follow-up work remains:
- Regroup execution errors by message/catalog type where appropriate
- Error overlay copy/layout updates for single vs multiple errors
- Right panel visual design updates
- Rendering `displayItemLabel` in the revised panel design
- More specific UI actions for auth, retry, and similar flows
- Broader fallthrough observability if we decide it is needed
Non-English locale files are intentionally not updated here. The
repository uses `src/locales/en/main.json` as the source of truth and
the release i18n sync flow generates the other locale files.
## Validation
Ran successfully:
- `pnpm format`
- `pnpm lint:unstaged`
- `pnpm typecheck`
- `pnpm test:unit`
- `pnpm vitest run
src/platform/errorCatalog/errorMessageResolver.test.ts`
- `pnpm vitest run
src/platform/errorCatalog/errorMessageResolver.test.ts
src/components/rightSidePanel/errors/useErrorGroups.test.ts`
- `pnpm build`
- `pnpm knip`
Notes:
- `pnpm build` still prints existing asset/icon and dynamic import
warnings, but exits successfully.
- `pnpm knip` exits successfully and still reports the existing
`flac.ts` tag hint.
## Screenshots (Before / After)
[Diff.zip](https://github.com/user-attachments/files/28300639/Diff.zip)
Uploaded as a ZIP file due to the image upload limit
## Summary
https://linear.app/comfyorg/issue/FE-867/bug-node-expand-menu-doesnt-work-nodes-immediately-collapse-after
Recreates #12175 on a fresh `main` base (original branch's CI failed
only because its `frontend-dist` artifact had expired — not a code
issue). Original work by @christian-byrne / Glary-Bot, cherry-picked
here so it can land while he's offline.
The Vue right-click "More Options" node menu shows duplicates for
collapse/expand functionality:
- **Vue source**: `Minimize Node` / `Expand Node` (works)
- **LiteGraph source**: `Resize`, `Collapse`, `Expand` (silently no-op
in this menu — the converter wrapper invokes
`LGraphCanvas.onMenuNodeCollapse` without the `node` arg it expects)
Suppress the LiteGraph duplicates in `convertContextMenuToOptions` by
matching the built-in **callback identity**
(`LGraphCanvas.onMenuResizeNode`, `LGraphCanvas.onMenuNodeCollapse`),
not the raw label. Matching by identity avoids accidentally hiding
extension-provided items that share those labels.
Also align `CORE_MENU_ITEMS` / `MENU_ORDER` on the Vue label `Expand
Node` so the toggled Minimize/Expand pair sorts correctly.
## Scope of suppression
Only the Vue node menu (via `convertContextMenuToOptions`) is affected.
The raw `LGraphCanvas.getNodeMenuOptions` output is untouched, so:
- The legacy right-click menu (`Comfy.UseNewMenu` disabled) still has
`Collapse` / `Resize`.
- `useLoad3d.ts`, which calls `new
LiteGraph.ContextMenu(app.canvas.getNodeMenuOptions(node), ...)`, is
unaffected.
- Extensions that monkey-patch `getNodeMenuOptions` continue to receive
the full option list.
## Tests
- `contextMenuConverter.test.ts`: covers both that built-in entries are
dropped by identity AND that extension-provided items with the same
labels survive.
- E2E `selectionToolboxMoreActions.spec.ts`: asserts the Vue "More
Options" menu shows `Minimize Node` but no `Resize`/`Collapse`/`Expand`.
- `pnpm typecheck` clean.
Supersedes #12175.
---------
Co-authored-by: Glary-Bot <glary-bot@users.noreply.github.com>
## Summary
1. Drop multi-object identity fields (uuid, name, type) since
multi-object support is not yet in scope, these are renderer-side
identifiers with no link back to the ComfyUI asset.
2. Drop rotation and matrix as redundant encodings of the same
transform, applying the same Jacob-redundancy point used on camera_info
3. Rename ModelTransform -> Model3DTransform and ModelInfo ->
Model3DInfo to align with the existing Load3D / File3D / model_3d naming
and disambiguate from AI 'model' (per Alexis).
4. The output key also moves from model_info to model_3d_info to match.
## Summary
Refactors middle mouse button pan handling around the intent of #11409,
dropping the outdated implementation details from that PR and aligning
the core behavior with the current main branch.
## Changes
- **What**: Centralized phase-specific middle mouse button handling in
`src/base/pointerUtils.ts`, added a shared Vue widget forwarding helper,
and updated canvas, LiteGraph, Vue node, and mask editor call sites to
use the same semantics.
- **Breaking**: None expected. This keeps existing middle-click pan
behavior while making pointerdown, pointermove, pointerup, and auxclick
checks explicit for their event phases.
- **Dependencies**: None.
## Review Focus
This PR is intentionally narrower than #11409. That PR had the right
goal, but its implementation became outdated against main: mask editor
tests now have helper coverage on main, Vue node/widget code has
shifted, and a blanket replacement with `isMiddlePointerInput` would
lose the bitmask behavior needed during pointermove drags.
The core difference is that this PR preserves the useful part of #11409,
namely removing scattered ad-hoc MMB checks, while avoiding stale
changes that no longer fit the current codebase.
Key behavior changes:
- `isMiddlePointerInput` is the conservative pointerdown-style check:
changed middle button or strict middle-only `buttons === 4`.
- `isMiddleButtonHeld` handles pointermove-style held-button bitmasks so
chorded drags with the middle button still pan.
- `isMiddleButtonEvent` handles pointerup/auxclick-style changed-button
events.
- Call sites now choose the phase-specific helper directly instead of
routing through an event-type dispatcher.
- String and markdown widgets now share
`forwardMiddleButtonToCanvas(...)` instead of duplicating three pointer
listeners each.
- The widget helper intentionally keeps the existing
`app.canvas.processMouseDown/Move/Up` forwarding route and only
centralizes the duplicated listener logic.
- Mask editor pan handling, Vue node pointer forwarding, graph canvas
pan forwarding, LiteGraph middle-click checks, input indicators, and
transform settling now use the centralized helpers.
Coverage added or updated:
- Unit coverage for middle-button helper semantics, including chorded
pointermove drags and pointercancel held-bit behavior.
- Unit coverage for widget forwarding helper down/move/up routing.
- Regression coverage for canvas, mask editor, Vue node media preview,
and transform-settling pointer handling.
- Browser coverage for middle-click drag panning on a Vue node, a
multiline string widget, and the mask editor canvas.
Validation run:
- `pnpm format`
- `pnpm lint`
- `pnpm typecheck`
- `pnpm test:unit src/base/pointerUtils.test.ts
src/renderer/extensions/vueNodes/widgets/utils/forwardMiddleButtonToCanvas.test.ts
src/renderer/extensions/vueNodes/widgets/composables/useStringWidget.test.ts
src/renderer/extensions/vueNodes/widgets/composables/useMarkdownWidget.test.ts
src/renderer/core/canvas/useCanvasInteractions.test.ts
src/composables/maskeditor/useToolManager.test.ts
src/renderer/core/layout/transform/useTransformSettling.test.ts
src/composables/node/useNodeImage.test.ts
src/composables/node/useNodeAnimatedImage.test.ts
src/components/graph/SelectionToolbox.test.ts
src/lib/litegraph/src/LGraphCanvas.slotHitDetection.test.ts`
- `pnpm typecheck:browser`
- `pnpm test:browser:local
browser_tests/tests/vueNodes/interactions/canvas/pan.spec.ts
browser_tests/tests/vueNodes/widgets/text/multilineStringWidget.spec.ts
browser_tests/tests/maskEditor.spec.ts --project chromium --grep
"Middle-click drag"`
- Commit hook: staged file format/lint, `pnpm typecheck`
## Screenshots (if applicable)
Not applicable; this is interaction behavior covered by unit and browser
tests.
## Summary
Upgrade ESLint from v9 to v10.4.0, bump compatible plugins/configs, and
fix the 32 violations introduced by the new `eslint:recommended` rules.
## Changes
- **What**:
- Catalog bumps in `pnpm-workspace.yaml`:
- `eslint` 9.39.1 → 10.4.0
- `@eslint/js` 9.39.1 → 10.0.1
- `typescript-eslint` 8.49.0 → 8.60.0
- `eslint-plugin-vue` 10.6.2 → 10.9.1
- `eslint-plugin-import-x` 4.16.1 → 4.16.2
- `eslint-plugin-unused-imports` 4.3.0 → 4.4.1
- `@intlify/eslint-plugin-vue-i18n` 4.1.1 → 4.5.0
- Fixed 4 `preserve-caught-error` violations by passing `{ cause }` to
rethrown errors in `useMaskEditorLoader.ts` and `usePainter.ts`.
- Fixed 28 `no-useless-assignment` violations across litegraph
(`LGraph.ts`, `LGraphCanvas.ts`, `LiteGraphGlobal.ts`, `polyfills.ts`)
and seven other files (`colorUtil.ts`, `linkFixer.ts`, `usePaste.ts`,
`audioService.ts`, `versionUtil.ts`, `subscriptionCheckoutTracker.ts`,
`ShiftClick.test.ts`) by removing dead initializers or redundant writes.
- Removed two now-unnecessary `@ts-expect-error` directives on
`importX.flatConfigs.*` (newer plugin ships correct types).
- **Breaking**: None for runtime; consumers using ESLint locally must
use Node ≥20.19/22.13/24 (already required by repo `engines.node:
">=25"`).
## Review Focus
- Audit of the [v10 migration
guide](https://eslint.org/docs/latest/use/migrate-to-10.0.0) found no
other patterns in this codebase to address (no `eslint-env` comments, no
removed `context.*`/`SourceCode` APIs, no `RuleTester` usage, no
affected rule configs).
- `no-useless-assignment` fixes were chosen conservatively: prefer
keeping the variable with a typed declaration over deleting the
statement, except where the assignment was clearly dead after the last
read.
- Per-file diffs in litegraph (especially `LGraphCanvas.ts`) — worth a
glance to confirm intent.
## Verification
- `pnpm exec eslint --version` → v10.4.0
- `pnpm exec eslint src` → 0 errors
- `pnpm typecheck` → clean
- Unit tests for every touched file pass (319/319 in spot checks:
`colorUtil`, `linkFixer`, `audioService`, `usePaste`, `usePainter`,
`versionUtil`, `LGraph`, `litegraph`, all `LGraphCanvas.*`,
`ShiftClick`).
Co-authored-by: Amp <amp@ampcode.com>
*PR Created by the Glary-Bot Agent*
---
## Problem
The GitHub star badge silently disappears from the comfy.org navigation.
Verified by curl-ing the live homepage:
```
props="{..."github-stars":[0,""]}"
```
`SiteNav.vue` only renders the badge when `githubStars` is truthy, so an
empty string hides it.
## Root cause
`apps/website/src/layouts/BaseLayout.astro` `await`s
`fetchGitHubStars('Comfy-Org', 'ComfyUI')` in its frontmatter. Astro
evaluates layout frontmatter **per rendered page** in SSG. With 379
pages (46 source `.astro` files × locales/dynamic routes), the
unauthenticated GitHub REST endpoint is called hundreds of times per
build, blasting past the 60 req/h anonymous rate limit. Once GitHub
returns 403 the existing `try/catch` returns `null`, `githubStars`
becomes `''`, and the badge vanishes — with no log line to indicate why.
## Fix
Cache the in-flight promise in a module-scope `Map` keyed by
`${owner}/${repo}` so every page in a single build shares one request.
Already-resolved counts stay cached, and the existing
`WEBSITE_GITHUB_STARS_OVERRIDE` env-var escape hatch still
short-circuits first.
While in the file:
- Pass an injectable `fetchImpl` so tests can stub without
`vi.spyOn(globalThis, 'fetch')`.
- Replace the implicit-`any` `data.stargazers_count ?? null` with a
narrow `readStargazerCount(data: unknown)` guard.
- In `BaseLayout.astro`, change `rawStars ? ...` to `rawStars !== null ?
...` so a hypothetical 0-star repo wouldn't be hidden (the old check
treated 0 as missing).
## Verification
- `pnpm --filter @comfyorg/website test:unit` → 89/89 pass (5 new test
cases: memoization, per-key isolation, non-2xx → null, throw → null,
override).
- `pnpm typecheck:website` → 0 errors.
- `pnpm format:check` → clean.
- `pnpm --filter @comfyorg/website build` → 379 pages built; with no
override set, output HTML contains `"github-stars":[0,"115K"]` (the live
count) on every page; with `WEBSITE_GITHUB_STARS_OVERRIDE=110000`, it
contains `"110K"` and `fetch` is never called.
- Playwright on the local preview confirms the badge renders at the
top-right of the nav with `aria-label="ComfyUI on GitHub — 110K stars"`.
## Scope
102 lines changed across 3 files (40 non-test). Deliberately leaves the
broader "snapshot fallback / build-data source" refactor to the existing
`codex/website-github-stars-once` branch — this PR just unblocks the
user-visible symptom.
## Screenshots
---------
Co-authored-by: Glary-Bot <glary-bot@users.noreply.github.com>
Co-authored-by: Alexander Brown <drjkl@comfy.org>
The "open tutorial" button only existed in the DOM when the template
card as actively hovered. For reasons I can not comprehend (probably
overzealous pointer handlers somewhere), the act of clicking on the
button would fire a mouseleave event. This caused the button to
disappear for the exact moment it was clicked alike to a mischievous
dondurma vendor.
This is resolved by keeping the button always in DOM, but making it
invisible when the card isn't hovered.
The PR also removes a deeply nested `v-bind='$attrs'`. I'm assuming it
must be a mistake that attributes applied to the entire template
selector dialogue would be bound to every deeply nested tutorial button
on individual workflow cards.
## Summary
- Long role titles wrapped awkwardly next to the inline department label
on the careers list, especially on narrow viewports.
- Restructured the role link so the title sits on its own row with the
arrow icon on the right, and the department + location wrap together on
a metadata row beneath (16px gap between them).
## Test plan
- [ ] Open `/careers` on mobile width and confirm long titles (e.g.
"Senior Software Engineer, Frontend") no longer collide with the
department label.
- [ ] Confirm desktop layout still reads cleanly.
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
- Adds a GitHub Actions workflow that detects PRs merged to `main`
without an approving review
- Creates tracking issues in
[`Comfy-Org/unreviewed-merges`](https://github.com/Comfy-Org/unreviewed-merges)
(private) for SOC 2 audit purposes
- Supports inline justification via `Justification: <reason>` in PR body
or comments
## How it works
Triggers on `push` to `main`. Uses the GitHub API to find the associated
PR and check for approving reviews. If none found, creates a tracking
issue with the `unreviewed-merge` label. No code checkout required — API
calls only.
## Test plan
- [ ] Verify workflow YAML is valid
- [ ] Merge a test PR without approval and confirm issue creation in
`unreviewed-merges` repo
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Amp <amp@ampcode.com>
## Summary
Adds visible loading feedback to the Workflows sidebar refresh button so
users can tell when a workflow sync request is in flight.
## Changes
- **What**: Exposes `isSyncLoading` from the workflow store and binds
the Workflows sidebar refresh button to disabled, `aria-busy`, and
spinning icon states while sync is pending.
- **What**: Adds stable E2E selectors for the workflows refresh button
and covers the loading state with unit and browser tests.
- **Dependencies**: None.
## Review Focus
Please verify the refresh control behavior while
`/api/userdata?dir=workflows` is pending, especially that the button is
disabled, exposes busy state, and returns to idle after sync completes.
## Validation
- `pnpm format`
- `pnpm test:unit
src/components/sidebar/tabs/BaseWorkflowsSidebarTab.test.ts`
- `pnpm test:browser:local browser_tests/tests/sidebar/workflows.spec.ts
-g "Shows loading state while refreshing workflows"`
- `pnpm lint`
- Commit hooks: `oxfmt`, `oxlint`, `eslint`, `typecheck`,
`typecheck:browser`
## Screenshots (if applicable)
https://github.com/user-attachments/assets/e8b893ae-a91d-45c9-81ea-adaf164de227
2026-05-28 17:31:42 +00:00
392 changed files with 26096 additions and 4448 deletions
en:'Built something cool with ComfyUI? <a href="https://docs.google.com/forms/d/1B6_RPQfhTyKvqHk9OO2bUn8z1Qgh6QIZsF3GNMiCXDw/preview" target="_blank" rel="noopener noreferrer" class="text-primary-comfy-yellow underline">Submit</a> your work to be featured on our website and socials and get seen by the global ComfyUI community.',
en:'Built something cool with ComfyUI?<br> <a href="https://docs.google.com/forms/d/1B6_RPQfhTyKvqHk9OO2bUn8z1Qgh6QIZsF3GNMiCXDw/preview" target="_blank" rel="noopener noreferrer" class="text-primary-comfy-yellow underline">Submit</a> your work to be featured on our website and socials and get seen by the global ComfyUI community.',
'If you have any questions regarding this Agreement or the Comfy Products, please contact us at: <a href="mailto:legal@comfy.org" class="text-white underline">legal@comfy.org</a>.'
},
// ── Affiliate Program Terms ───────────────────────────────────────
// Legal-reviewed copy — ENGLISH ONLY. There is no /zh-CN/affiliates/terms
// route, and the `'zh-CN'` values below intentionally duplicate `en`
// verbatim only to satisfy the translations dictionary's required
// Record<Locale, string> shape. Do NOT translate these into Chinese:
// shipping an unreviewed translation as the active terms exposes us to
// liability from the translation diverging from the legal-approved
// English source. If a translated terms page is ever needed, add a
// separate `/affiliates/terms/<locale>` route only after legal signs
// off on that specific translation as the authoritative version.
'affiliate-terms.effective-date':{
en:'May 16, 2026',
'zh-CN':'May 16, 2026'
},
'affiliate-terms.1-program-overview.label':{
en:'PROGRAM',
'zh-CN':'PROGRAM'
},
'affiliate-terms.1-program-overview.title':{
en:'1. Program Overview',
'zh-CN':'1. Program Overview'
},
'affiliate-terms.1-program-overview.block.0':{
en:'The <a href="https://comfy.org" class="text-white underline">Comfy.org</a> Affiliate Program ("<strong>Program</strong>") allows approved participants ("<strong>Affiliates</strong>") to earn commissions by referring new paying customers to Comfy Cloud. By participating in this program, you agree to these terms.',
'zh-CN':
'The <a href="https://comfy.org" class="text-white underline">Comfy.org</a> Affiliate Program ("<strong>Program</strong>") allows approved participants ("<strong>Affiliates</strong>") to earn commissions by referring new paying customers to Comfy Cloud. By participating in this program, you agree to these terms.'
},
'affiliate-terms.2-eligible-products.label':{
en:'PRODUCTS',
'zh-CN':'PRODUCTS'
},
'affiliate-terms.2-eligible-products.title':{
en:'2. Eligible Products',
'zh-CN':'2. Eligible Products'
},
'affiliate-terms.2-eligible-products.block.0':{
en:'Commissions are earned on Comfy Cloud paid subscription plans only. The following are excluded from commission eligibility: free tier signups (unless they later convert to paid), one-time credit purchases, enterprise contracts negotiated directly with Comfy sales, and API-only usage billed outside of standard subscription plans.',
'zh-CN':
'Commissions are earned on Comfy Cloud paid subscription plans only. The following are excluded from commission eligibility: free tier signups (unless they later convert to paid), one-time credit purchases, enterprise contracts negotiated directly with Comfy sales, and API-only usage billed outside of standard subscription plans.'
en:'Commission rate: 30% recurring on the net subscription amount received by Comfy.org\nCommission duration: 3 months from the referred customer\u2019s first paid subscription\nCookie/attribution window: 60 days from the referral click\nMinimum payout threshold: $100\nPayout schedule: Monthly, within the first 10 business days of each month after the receipt of applicable payment by Comfy from its referred customer\nPayout method: Via the affiliate tracking platform (Stripe Express or PayPal)\nCommission cessation: To the extent a referred customer\u2019s subscription is canceled, in whole or in part, the affiliate shall correspondingly cease to receive commission payments, even within the 3-month commission window. Refunded or charged-back transactions are not eligible for commission, and any commission previously paid for such transactions will be deducted from future payouts (see Section 4).',
'zh-CN':
'Commission rate: 30% recurring on the net subscription amount received by Comfy.org\nCommission duration: 3 months from the referred customer\u2019s first paid subscription\nCookie/attribution window: 60 days from the referral click\nMinimum payout threshold: $100\nPayout schedule: Monthly, within the first 10 business days of each month after the receipt of applicable payment by Comfy from its referred customer\nPayout method: Via the affiliate tracking platform (Stripe Express or PayPal)\nCommission cessation: To the extent a referred customer\u2019s subscription is canceled, in whole or in part, the affiliate shall correspondingly cease to receive commission payments, even within the 3-month commission window. Refunded or charged-back transactions are not eligible for commission, and any commission previously paid for such transactions will be deducted from future payouts (see Section 4).'
},
'affiliate-terms.4-attribution-rules.label':{
en:'ATTRIBUTION',
'zh-CN':'ATTRIBUTION'
},
'affiliate-terms.4-attribution-rules.title':{
en:'4. Attribution Rules',
'zh-CN':'4. Attribution Rules'
},
'affiliate-terms.4-attribution-rules.block.0':{
en:'Commissions are attributed on a last-click basis within the 60-day cookie window\nIf a referred customer cancels and re-subscribes within 60 days, the original affiliate retains attribution\nIf a referred customer upgrades their plan, commission is calculated on the upgraded amount\nIf a referred customer downgrades their plan, commission adjusts to the new plan amount\nRefunded transactions are not eligible for commission\nAny commission paid on refunded transactions will be deducted from future payouts to you',
'zh-CN':
'Commissions are attributed on a last-click basis within the 60-day cookie window\nIf a referred customer cancels and re-subscribes within 60 days, the original affiliate retains attribution\nIf a referred customer upgrades their plan, commission is calculated on the upgraded amount\nIf a referred customer downgrades their plan, commission adjusts to the new plan amount\nRefunded transactions are not eligible for commission\nAny commission paid on refunded transactions will be deducted from future payouts to you'
en:'<strong>Self-refer</strong>: Use your own affiliate link to purchase or receive discounts on your own account\n<strong>Bid on branded keywords</strong>: Run paid search campaigns (Google Ads, Bing Ads, etc.) targeting "ComfyUI," "Comfy.org," "Comfy Cloud," or any misspellings or variations thereof\n<strong>Misrepresent</strong>: Impersonate Comfy.org, claim to be an employee, or create assets that could be confused with official Comfy.org materials\n<strong>Spam</strong>: Send unsolicited bulk emails, messages, or engage in any form of spam promotion\n<strong>Cookie stuff</strong>: Use hidden iframes, pop-unders, or any technical means to set cookies without genuine user intent\n<strong>Incentivize clicks</strong>: Offer monetary rewards, points, or other incentives solely for clicking your affiliate link (content recommendations are fine)\n<strong>Use misleading claims</strong>: Make false or exaggerated claims about Comfy.org products, pricing, or features\n<strong>Promote on prohibited content</strong>: Place affiliate links on sites containing illegal content, hate speech, or adult content\n<strong>Contrary to laws</strong>: Place affiliate links in any market that is prohibited as a region under the laws of the United States of America.',
'zh-CN':
'<strong>Self-refer</strong>: Use your own affiliate link to purchase or receive discounts on your own account\n<strong>Bid on branded keywords</strong>: Run paid search campaigns (Google Ads, Bing Ads, etc.) targeting "ComfyUI," "Comfy.org," "Comfy Cloud," or any misspellings or variations thereof\n<strong>Misrepresent</strong>: Impersonate Comfy.org, claim to be an employee, or create assets that could be confused with official Comfy.org materials\n<strong>Spam</strong>: Send unsolicited bulk emails, messages, or engage in any form of spam promotion\n<strong>Cookie stuff</strong>: Use hidden iframes, pop-unders, or any technical means to set cookies without genuine user intent\n<strong>Incentivize clicks</strong>: Offer monetary rewards, points, or other incentives solely for clicking your affiliate link (content recommendations are fine)\n<strong>Use misleading claims</strong>: Make false or exaggerated claims about Comfy.org products, pricing, or features\n<strong>Promote on prohibited content</strong>: Place affiliate links on sites containing illegal content, hate speech, or adult content\n<strong>Contrary to laws</strong>: Place affiliate links in any market that is prohibited as a region under the laws of the United States of America.'
},
'affiliate-terms.6-content-guidelines.label':{
en:'CONTENT & IP',
'zh-CN':'CONTENT & IP'
},
'affiliate-terms.6-content-guidelines.title':{
en:'6. Content Guidelines and Intellectual Property Rights',
'zh-CN':'6. Content Guidelines and Intellectual Property Rights'
},
'affiliate-terms.6-content-guidelines.block.0':{
en:'Affiliates must clearly disclose the affiliate relationship in accordance with FTC guidelines (US) and equivalent regulations in their jurisdiction\nRecommended disclosure: "This page contains affiliate links. I may earn a commission if you sign up through my link."\nAffiliates may use Comfy.org logos and brand assets only as provided in the official affiliate asset kit, and may not modify them\nComfy.org retains all rights, including in any of its intellectual property apart from the limited use rights granted herein',
'zh-CN':
'Affiliates must clearly disclose the affiliate relationship in accordance with FTC guidelines (US) and equivalent regulations in their jurisdiction\nRecommended disclosure: "This page contains affiliate links. I may earn a commission if you sign up through my link."\nAffiliates may use Comfy.org logos and brand assets only as provided in the official affiliate asset kit, and may not modify them\nComfy.org retains all rights, including in any of its intellectual property apart from the limited use rights granted herein'
},
'affiliate-terms.7-termination.label':{
en:'TERMINATION',
'zh-CN':'TERMINATION'
},
'affiliate-terms.7-termination.title':{
en:'7. Termination',
'zh-CN':'7. Termination'
},
'affiliate-terms.7-termination.block.0':{
en:'Either party may terminate the affiliate relationship at any time with 14 days\u2019 prior written notice\nComfy.org reserves the right to immediately terminate and withhold commissions if an affiliate violates any of the prohibited activities listed above\nUpon termination, any unpaid commissions above the minimum threshold will be paid in the next regular payout cycle\nCommissions on referred customers will cease at the time of termination, even if within the 3-month commission window',
'zh-CN':
'Either party may terminate the affiliate relationship at any time with 14 days\u2019 prior written notice\nComfy.org reserves the right to immediately terminate and withhold commissions if an affiliate violates any of the prohibited activities listed above\nUpon termination, any unpaid commissions above the minimum threshold will be paid in the next regular payout cycle\nCommissions on referred customers will cease at the time of termination, even if within the 3-month commission window'
en:'Comfy.org reserves the right to modify these terms, commission rates, or program structure with 30 days notice to active affiliates\nContinued participation after notice constitutes acceptance of modified terms',
'zh-CN':
'Comfy.org reserves the right to modify these terms, commission rates, or program structure with 30 days notice to active affiliates\nContinued participation after notice constitutes acceptance of modified terms'
},
'affiliate-terms.9-indemnification.label':{
en:'LIABILITY',
'zh-CN':'LIABILITY'
},
'affiliate-terms.9-indemnification.title':{
en:'9. Indemnification and Limitation of Liability',
'zh-CN':'9. Indemnification and Limitation of Liability'
},
'affiliate-terms.9-indemnification.block.0':{
en:'You will indemnify Comfy.org from any third party claim arising out of your breach of these terms.\nComfy.org\u2019s liability to any affiliate shall not (i) exceed the total commissions paid to that affiliate in the preceding 12 months, and (ii) include any indirect, consequential, punitive or any other type of special damages.\nComfy.org is not responsible for tracking failures caused by user browser settings, ad blockers, or VPNs, though we employ server-side tracking to minimize these issues',
'zh-CN':
'You will indemnify Comfy.org from any third party claim arising out of your breach of these terms.\nComfy.org\u2019s liability to any affiliate shall not (i) exceed the total commissions paid to that affiliate in the preceding 12 months, and (ii) include any indirect, consequential, punitive or any other type of special damages.\nComfy.org is not responsible for tracking failures caused by user browser settings, ad blockers, or VPNs, though we employ server-side tracking to minimize these issues'
},
'affiliate-terms.10-governing-law.label':{
en:'GOVERNING LAW',
'zh-CN':'GOVERNING LAW'
},
'affiliate-terms.10-governing-law.title':{
en:'10. Governing Law',
'zh-CN':'10. Governing Law'
},
'affiliate-terms.10-governing-law.block.0':{
en:'These terms shall be governed by and construed in accordance with the laws of the State of Delaware, without regard to conflict of law principles. All disputes arising under this Agreement shall be resolved exclusively in the state or federal courts in the State of Delaware.',
'zh-CN':
'These terms shall be governed by and construed in accordance with the laws of the State of Delaware, without regard to conflict of law principles. All disputes arising under this Agreement shall be resolved exclusively in the state or federal courts in the State of Delaware.'
},
'affiliate-terms.11-miscellaneous.label':{
en:'MISCELLANEOUS',
'zh-CN':'MISCELLANEOUS'
},
'affiliate-terms.11-miscellaneous.title':{
en:'11. Miscellaneous',
'zh-CN':'11. Miscellaneous'
},
'affiliate-terms.11-miscellaneous.block.0':{
en:'<strong>(a) Entire Agreement.</strong> These terms constitutes the sole and entire agreement (including the attached schedules and exhibits) of the Parties with respect to the subject matter of these terms, and supersedes all prior and contemporaneous understandings, agreements, representations, and warranties, both written and oral, with respect to the subject matter. <strong>(b) Relationship of Parties.</strong> Each party is an independent contractor with regard to these terms. Nothing contained in These terms shall be construed as creating any agency, partnership, joint venture, or other form of joint enterprise, employment, or fiduciary relationship between the Parties. Neither party, by virtue of these terms, will have any right, power, or authority to act or create an obligation, express or implied, on behalf of the other party. <strong>(c) Assignment.</strong> Neither party shall assign any of its rights or delegate any of its obligations hereunder without the prior written consent of the other party, which consent shall not be unreasonably withheld, conditioned or delayed. <strong>(d) Severability.</strong> If any term or provision of these terms is invalid, illegal, or unenforceable in any jurisdiction, such invalidity, illegality, or unenforceability shall not affect any other term or provision of these terms or invalidate or render unenforceable such term or provision in any other jurisdiction. Upon a determination that any term or provision is invalid, illegal or unenforceable, the Parties hereto shall negotiate in good faith to modify these terms to effect the original intent of the Parties as closely as possible in order that the transactions contemplated hereby be consummated as originally contemplated to the greatest extent possible. <strong>(e) Waiver.</strong> No waiver by either party of any of the provisions hereof shall be effective unless explicitly set forth in writing and signed by the party so waiving. <strong>(f) Notice.</strong> Each party shall deliver all notices, requests, consents, claims, demands, waivers, and other communications under these terms in writing to the email utilized for the primary contact for the other party. <strong>(g) Cumulative Remedies.</strong> All rights and remedies provided in these terms are cumulative and not exclusive, and the exercise by a party of any right or remedy does not preclude the exercise of any other rights or remedies that may now or subsequently be available at Law, in equity, by statute, in any other agreement between the Parties or otherwise. <strong>(h) No Third-Party Beneficiaries.</strong> These terms benefits solely the Parties to these terms and their respective permitted successors and assigns and nothing in these terms, express or implied, confers on any other person or entity any legal or equitable right, benefit, or remedy of any nature whatsoever under or by reason of these terms.',
'zh-CN':
'<strong>(a) Entire Agreement.</strong> These terms constitutes the sole and entire agreement (including the attached schedules and exhibits) of the Parties with respect to the subject matter of these terms, and supersedes all prior and contemporaneous understandings, agreements, representations, and warranties, both written and oral, with respect to the subject matter. <strong>(b) Relationship of Parties.</strong> Each party is an independent contractor with regard to these terms. Nothing contained in These terms shall be construed as creating any agency, partnership, joint venture, or other form of joint enterprise, employment, or fiduciary relationship between the Parties. Neither party, by virtue of these terms, will have any right, power, or authority to act or create an obligation, express or implied, on behalf of the other party. <strong>(c) Assignment.</strong> Neither party shall assign any of its rights or delegate any of its obligations hereunder without the prior written consent of the other party, which consent shall not be unreasonably withheld, conditioned or delayed. <strong>(d) Severability.</strong> If any term or provision of these terms is invalid, illegal, or unenforceable in any jurisdiction, such invalidity, illegality, or unenforceability shall not affect any other term or provision of these terms or invalidate or render unenforceable such term or provision in any other jurisdiction. Upon a determination that any term or provision is invalid, illegal or unenforceable, the Parties hereto shall negotiate in good faith to modify these terms to effect the original intent of the Parties as closely as possible in order that the transactions contemplated hereby be consummated as originally contemplated to the greatest extent possible. <strong>(e) Waiver.</strong> No waiver by either party of any of the provisions hereof shall be effective unless explicitly set forth in writing and signed by the party so waiving. <strong>(f) Notice.</strong> Each party shall deliver all notices, requests, consents, claims, demands, waivers, and other communications under these terms in writing to the email utilized for the primary contact for the other party. <strong>(g) Cumulative Remedies.</strong> All rights and remedies provided in these terms are cumulative and not exclusive, and the exercise by a party of any right or remedy does not preclude the exercise of any other rights or remedies that may now or subsequently be available at Law, in equity, by statute, in any other agreement between the Parties or otherwise. <strong>(h) No Third-Party Beneficiaries.</strong> These terms benefits solely the Parties to these terms and their respective permitted successors and assigns and nothing in these terms, express or implied, confers on any other person or entity any legal or equitable right, benefit, or remedy of any nature whatsoever under or by reason of these terms.'
},
'affiliate-terms.page.title':{
en:'Affiliate Terms — Comfy',
'zh-CN':'Affiliate Terms — Comfy'
},
'affiliate-terms.page.description':{
en:'Comfy.org Affiliate Program Terms and Conditions.',
'zh-CN':'Comfy.org Affiliate Program Terms and Conditions.'
},
'affiliate-terms.page.heading':{
en:'Affiliate Terms',
'zh-CN':'Affiliate Terms'
},
'affiliate-terms.page.tocLabel':{
en:'On this page',
'zh-CN':'本页内容'
},
'affiliate-terms.page.effectiveDateLabel':{
en:'Effective Date',
'zh-CN':'生效日期'
},
// Customers page
'customers.hero.label':{
en:'CUSTOMER STORIES',
@@ -4235,6 +4422,315 @@ const translations = {
'payment.failed.secondaryCta':{
en:'READ SUBSCRIPTION DOCS',
'zh-CN':'查看订阅文档'
},
// Affiliate landing page (/affiliates)
// English-only copy; zh-CN values mirror en until a localized version lands.
'affiliate-landing.page.title':{
en:'Comfy.org Affiliate Program — Become a Partner',
'zh-CN':'Comfy.org Affiliate Program — Become a Partner'
},
'affiliate-landing.page.description':{
en:'Earn 30% recurring commission for 3 months on every Comfy Cloud subscription you refer. Apply to become a Comfy Partner.',
'zh-CN':
'Earn 30% recurring commission for 3 months on every Comfy Cloud subscription you refer. Apply to become a Comfy Partner.'
},
'affiliate-landing.cta.apply':{
en:'Apply Now',
'zh-CN':'Apply Now'
},
'affiliate-landing.cta.applyAriaLabel':{
en:'Apply Now (opens in new tab)',
'zh-CN':'Apply Now (opens in new tab)'
},
// Hero
'affiliate-landing.hero.heading':{
en:'Become a Comfy Partner',
'zh-CN':'Become a Comfy Partner'
},
'affiliate-landing.hero.subheading':{
en:'Earn 30% Commission for 3 Months.',
'zh-CN':'Earn 30% Commission for 3 Months.'
},
'affiliate-landing.hero.body':{
en:'Join the Comfy.org Affiliate Program and earn 30% recurring commission for 3 months on every Comfy Cloud subscription you refer:',
'zh-CN':
'Join the Comfy.org Affiliate Program and earn 30% recurring commission for 3 months on every Comfy Cloud subscription you refer:'
},
'affiliate-landing.hero.highlight.0':{
en:'30% recurring commission for 3 months',
'zh-CN':'30% recurring commission for 3 months'
},
'affiliate-landing.hero.highlight.1':{
en:'60-day cookie window',
'zh-CN':'60-day cookie window'
},
'affiliate-landing.hero.highlight.2':{
en:'$100 minimum payout',
'zh-CN':'$100 minimum payout'
},
'affiliate-landing.hero.highlight.3':{
en:'Monthly payouts',
'zh-CN':'Monthly payouts'
},
// Trust band
'affiliate-landing.trust.label':{
en:'Trusted by 2M+ creators worldwide',
'zh-CN':'Trusted by 2M+ creators worldwide'
},
// How it works
'affiliate-landing.how.heading':{
en:'How it works',
'zh-CN':'How it works'
},
'affiliate-landing.how.step.0.title':{
en:'Apply.',
'zh-CN':'Apply.'
},
'affiliate-landing.how.step.0.body':{
en:'Submit a quick form. Most applicants approved same day.',
'zh-CN':'Submit a quick form. Most applicants approved same day.'
},
'affiliate-landing.how.step.1.title':{
en:'Share.',
'zh-CN':'Share.'
},
'affiliate-landing.how.step.1.body':{
en:'Get your unique tracking link. Share via content, social, email, however you reach your audience.',
'zh-CN':
'Get your unique tracking link. Share via content, social, email, however you reach your audience.'
},
'affiliate-landing.how.step.2.title':{
en:'Earn.',
'zh-CN':'Earn.'
},
'affiliate-landing.how.step.2.body':{
en:'30% recurring commission for 3 months on every Comfy Cloud subscriber you refer. Tracked in real-time. Paid monthly.',
'zh-CN':
'30% recurring commission for 3 months on every Comfy Cloud subscriber you refer. Tracked in real-time. Paid monthly.'
},
// Who we're looking for
'affiliate-landing.audience.heading':{
en:"Who we're looking for",
'zh-CN':"Who we're looking for"
},
'affiliate-landing.audience.item.0':{
en:'ComfyUI tutorial creators and workflow builders',
'zh-CN':'ComfyUI tutorial creators and workflow builders'
},
'affiliate-landing.audience.item.1':{
en:'AI tool reviewers on YouTube, TikTok, blogs',
'zh-CN':'AI tool reviewers on YouTube, TikTok, blogs'
},
'affiliate-landing.audience.item.2':{
en:'Tech bloggers covering AI creative tools',
'zh-CN':'Tech bloggers covering AI creative tools'
},
'affiliate-landing.audience.item.3':{
en:'Newsletter operators in the AI/creative space',
'zh-CN':'Newsletter operators in the AI/creative space'
},
'affiliate-landing.audience.item.4':{
en:'Anyone with an audience interested in AI image, video, or 3D generation',
'zh-CN':
'Anyone with an audience interested in AI image, video, or 3D generation'
},
// Program details
'affiliate-landing.details.heading':{
en:'Program details',
'zh-CN':'Program details'
},
'affiliate-landing.details.headerLabel':{
en:'Detail',
'zh-CN':'Detail'
},
'affiliate-landing.details.headerValue':{
en:'Value',
'zh-CN':'Value'
},
'affiliate-landing.details.row.0.label':{
en:'Commission rate',
'zh-CN':'Commission rate'
},
'affiliate-landing.details.row.0.value':{
en:'30% recurring',
'zh-CN':'30% recurring'
},
'affiliate-landing.details.row.1.label':{
en:'Commission duration',
'zh-CN':'Commission duration'
},
'affiliate-landing.details.row.1.value':{
en:'3 months',
'zh-CN':'3 months'
},
'affiliate-landing.details.row.2.label':{
en:'Cookie window',
'zh-CN':'Cookie window'
},
'affiliate-landing.details.row.2.value':{
en:'60 days',
'zh-CN':'60 days'
},
'affiliate-landing.details.row.3.label':{
en:'Eligible products',
'zh-CN':'Eligible products'
},
'affiliate-landing.details.row.3.value':{
en:'Comfy Cloud paid subscription plans',
'zh-CN':'Comfy Cloud paid subscription plans'
},
'affiliate-landing.details.row.4.label':{
en:'Payouts',
'zh-CN':'Payouts'
},
'affiliate-landing.details.row.4.value':{
en:'Monthly, within first 10 business days',
'zh-CN':'Monthly, within first 10 business days'
},
'affiliate-landing.details.row.5.label':{
en:'Minimum payout',
'zh-CN':'Minimum payout'
},
'affiliate-landing.details.row.5.value':{
en:'$100',
'zh-CN':'$100'
},
// Brand assets
'affiliate-landing.assets.heading':{
en:'Brand assets',
'zh-CN':'Brand assets'
},
'affiliate-landing.assets.subheading':{
en:'Approved Comfy logos for your content. Banners, screenshots, and talking points are in your affiliate dashboard after approval.',
'zh-CN':
'Approved Comfy logos for your content. Banners, screenshots, and talking points are in your affiliate dashboard after approval.'
'zh-CN':'Most applications approved within 24 hours.'
},
'affiliate-landing.faq.4.q':{
en:'When do I get paid?',
'zh-CN':'When do I get paid?'
},
'affiliate-landing.faq.4.a':{
en:'Monthly, within the first 10 business days. Minimum balance $100. Paid via Stripe Express or PayPal.',
'zh-CN':
'Monthly, within the first 10 business days. Minimum balance $100. Paid via Stripe Express or PayPal.'
},
'affiliate-landing.faq.5.q':{
en:'What happens if my referral upgrades or downgrades?',
'zh-CN':'What happens if my referral upgrades or downgrades?'
},
'affiliate-landing.faq.5.a':{
en:'If they upgrade, your commission increases. If they downgrade, it adjusts accordingly. Commission is based on actual amounts received by Comfy.org, net of refunds.',
'zh-CN':
'If they upgrade, your commission increases. If they downgrade, it adjusts accordingly. Commission is based on actual amounts received by Comfy.org, net of refunds.'
},
'affiliate-landing.faq.6.q':{
en:'Can I use coupon codes?',
'zh-CN':'Can I use coupon codes?'
},
'affiliate-landing.faq.6.a':{
en:'Yes. We support both tracking links and unique coupon codes.',
'zh-CN':'Yes. We support both tracking links and unique coupon codes.'
},
'affiliate-landing.faq.7.q':{
en:'What if my referral uses an ad blocker?',
'zh-CN':'What if my referral uses an ad blocker?'
},
'affiliate-landing.faq.7.a':{
en:'We use server-side tracking, so conversions are tracked regardless.',
'zh-CN':
'We use server-side tracking, so conversions are tracked regardless.'
},
'affiliate-landing.faq.8.q':{
en:'What assets do you provide?',
'zh-CN':'What assets do you provide?'
},
'affiliate-landing.faq.8.a':{
en:'Logos and banners on this page, plus screenshots and talking points in your affiliate dashboard after approval.',
'zh-CN':
'Logos and banners on this page, plus screenshots and talking points in your affiliate dashboard after approval.'
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
