[pull] main from Comfy-Org:main - #34
Merged
Merged
Conversation
## Automated API Type Update This PR updates the Comfy Registry API types from the latest comfy-api OpenAPI specification in the cloud monorepo. - Cloud commit: 94d0f1b - Source: `services/comfy-api/openapi.yml` These types are generated from the frontend-facing projection of the spec using openapi-typescript. Internal and admin operations are excluded. Co-authored-by: coderfromthenorth93 <213232275+coderfromthenorth93@users.noreply.github.com>
## Summary Pasted and duplicated nodes register widgets before their deferred missing-model and missing-media scans finish. The right-side panel could therefore recalculate its tabs, see no selected-node error yet, and switch away from Errors permanently. This change tracks graph-scoped added-node scans from node addition through asynchronous verification. An already-active Errors tab remains available while its selected node is being scanned, then either stays active when an error surfaces or falls back when the scan settles cleanly. Scan lifecycle handling now: - reference-counts overlapping scans by root graph and execution ID - releases the tab hold without aborting valid verification during subgraph navigation - aborts verification when the scanned node is removed - suppresses late results after workflow/node replacement, widget changes, or ownership changes - waits for already-started verification when a later scan stage fails ## Testing - Added focused component coverage for pending, error, clean fallback, unmount, and subgraph-interior selection behavior. - Added lifecycle coverage for overlapping scans, graph isolation, disposal, workflow replacement, model/media cancellation, changed values, and scan-stage failures. - Added a Playwright flow covering paste, delayed cloud verification, retained Errors selection, surfaced errors, and clean fallback after resolution. - `pnpm test:unit src/components/rightSidePanel/RightSidePanel.test.ts src/composables/graph/useErrorClearingHooks.test.ts src/stores/executionErrorStore.test.ts` - `pnpm typecheck` - ESLint and Oxfmt on changed files --------- Co-authored-by: Amp <amp@ampcode.com> Co-authored-by: GitHub Action <action@github.com>
## Summary Adds `/minimax-music-3` and `/zh-CN/minimax-music-3`, cloned from the MiniMax H3 page on the shared model-launch template. Structure and copy are in place; assets and final copy are to be taken over. ## Changes - **Data**: `data/minimaxMusic3.ts` — page config (hero, audio gallery, pricing, Q&A, closing CTA, run options, reviews) - **Pages**: `pages/minimax-music-3.astro` + the zh-CN stub - **Routing**: `routes.ts` (`minimaxMusic3: '/minimax-music-3'`) and `routes.test.ts` cases - **i18n**: `i18n/translations.ts` — `minimaxMusic3.*` keys, English plus zh-CN - **Template**: new `AudioPlayer` + audio gallery section/sample card, hero CTA button and type updates on the shared model-launch template - **Tests**: `modelLaunchPages.test.ts` registers the config for shared invariants Ported from Comfy-Org/ComfyUI_frontend-private#36. ## Review Focus - The audio gallery additions to the shared model-launch template (`AudioPlayer`, `ModelLaunchAudioGallerySection`, `ModelLaunchAudioSampleCard`) — first audio-based launch page, so confirm the template changes don't regress existing video-based pages. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: GitHub Action <action@github.com>
Automatic SHA bump — `cursor-review.yml` was updated in `Comfy-Org/github-workflows` at [`732100b`](Comfy-Org/github-workflows@732100b). _Opened by the `bump-cursor-review-callers` workflow._ Co-authored-by: cloud-code-bot[bot] <234529496+cloud-code-bot[bot]@users.noreply.github.com>
## Automated Ingest API Type Update This PR updates the Ingest API TypeScript types and Zod schemas from the latest cloud OpenAPI specification. - Cloud commit: 94d0f1b - Generated using @hey-api/openapi-ts with Zod plugin These types cover the FE-facing ingest API (workspaces, billing, secrets, assets, tasks, etc.). Cloud's internal / machine-to-machine surface — `x-internal` operations and the `/admin/`, `/api/internal/`, `/api/webhooks/` rails — is stripped before generation (BE-2669), so it is not code-generated into this public package. --------- Co-authored-by: mattmillerai <7741082+mattmillerai@users.noreply.github.com> Co-authored-by: GitHub Action <action@github.com>
<!-- ccr-slack-attribution --> _Requested by **Robert Paige** · [Slack thread](https://comfy-organization.slack.com/archives/C09NWURUPMF/p1785900405679469?thread_ts=1785900405.679469&cid=C09NWURUPMF)_ ## Summary Swaps the `/minimax` hero clip for `hero-sizzle.mp4` and adds a mobile still fallback so phones never fetch the ~19MB video. ## Before / After - **Desktop, before**: hero played `hero.mp4`. - **Desktop, after**: hero plays `hero-sizzle.mp4` (66s), same as before otherwise — video hydrates in after the page loads. - **Phone (<768px), before**: the page still requested the full hero video in the background even though the video element wasn't the focus of the layout. - **Phone (<768px), after**: the page shows a static `hero-fallback.jpg` still in the hero and never requests any hero video file — no `<video>` tag is emitted at all below the 768px breakpoint, on the server-rendered HTML or on the client's first render. ## Changes - **What**: - `apps/website/src/data/minimax.ts`: points `hero.videoSrc` at `hero-sizzle.mp4` and adds `hero.mobileFallbackImageSrc` pointing at `hero-fallback.jpg` (both served from `media.comfy.org`). - `apps/website/src/templates/model-launch/types.ts`: adds an optional `mobileFallbackImageSrc` field to `ModelLaunchHero`. It's opt-in — pages that don't set it (there are currently no others with a video hero) keep rendering their `<video>` unconditionally, exactly as before. - `apps/website/src/templates/model-launch/ModelLaunchHeroSection.vue`: when `mobileFallbackImageSrc` is set, the hero only renders `<VideoPlayer>` once mounted on a `>=768px` viewport (`useMounted` + `useMediaQuery('(min-width: 768px)')` from VueUse); otherwise it renders the fallback `<img>`. Since this is an Astro island (`client:load`), the server-rendered HTML and the client's pre-mount render both take the "no video" branch — confirmed in a production build that `/minimax`'s SSR output contains the fallback `<img>` and zero `<video>` tags for the hero (the model-gallery section's own videos are unaffected, `client:visible` + `preload="none"`, unrelated to this change). The `<video>`/`src` never reaches the DOM until `onMounted` confirms desktop width, so mobile never starts a request for the clip. - `apps/website/e2e/minimax.spec.ts`: adds a desktop test asserting the hero video hydrates with the new src, and a `@mobile` test asserting no request for `hero-sizzle.mp4` is ever made and the fallback image is shown instead. Also fixes an unrelated pre-existing `astro check` failure (`minimaxPage.faq` possibly `undefined`) that was blocking the repo's pre-commit hook for any `apps/website` change. - **Breaking**: none. ## Review Focus `apps/website` is a plain Astro SSG/SSR site (islands hydrate via `client:load`/`client:visible`), not the main Vue SPA — the hydration-mismatch risk is real here, not hypothetical. I verified with a real `astro build` that the SSR HTML for `/minimax` (and `/zh-CN/minimax`) contains only the fallback `<img>` for the hero, no `<video>` tag, so there's no flash/mismatch and no eager fetch path for mobile to fall through. ## Screenshots (if applicable) N/A — no visual change on desktop; mobile swaps a video frame for an explicit still image at the same aspect ratio. --- _Generated by [Claude Code](https://claude.ai/code/session_01JQfWmFuxF31yFLsgVXimjy)_ --------- Co-authored-by: Claude <noreply@anthropic.com>
…15161) ## Summary A runtime credits refusal leaves the workflow's execution status stuck at `running` forever. ## Changes - **What**: `handleAccountPreconditionError` in `src/stores/executionStore.ts` now clears the workflow's `workflowStatus` entry before resetting execution state. Mechanism on `main`: - `handleExecutionError` calls `handleAccountPreconditionError(e.detail)` and returns early when it returns true. These errors (`INSUFFICIENT_CREDITS` / `WORKSPACE_INSUFFICIENT_CREDITS`, routed via `resolveAccountPrecondition`) open their own modal and are deliberately kept out of the error panel and error count. - `handleAccountPreconditionError` only called `clearInitializationByJobId` then `resetExecutionState`. - `resetExecutionState` deletes `queuedJobs[jobId]` and the `jobIdToWorkflow` entry, but never touches `workflowStatus`. These are runtime errors: the job was accepted, got a machine, and `execution_start` already wrote `running` before the refusal arrives. So the status map keeps `running` indefinitely, and every reader of `getWorkflowStatus` (status badges, the first-run tour result card) promises a result that will never arrive. `handleExecutionInterrupted` already does the right thing and is the precedent this copies. Ordering matters: the `jobIdToWorkflow` lookup and status clear must happen before `resetExecutionState`, which deletes that mapping. ## Review Focus - Clearing rather than writing `failed` is intentional and matches the interrupt path — an account precondition is a gating state with its own modal, not a workflow failure, so it should leave no badge. - Sibling early-return branches (`handleServiceLevelError`, `handleCloudValidationError`) were left alone. Service-level errors have an existing test asserting the status stays `running`, so changing that is a separate decision. - Unit test added in `src/stores/executionStore.test.ts`: paid-style credits payload after `execution_start`, asserting the status goes from `running` to cleared. Verified it fails on `main` (`expected 'running' to be undefined`) and passes with the fix. Found while reviewing #15091. Distinct from #14619, which covers the submit-time refusal where no `prompt_id` is ever issued and the status never passes through `running` at all; this is the accepted-then-refused runtime path. Co-authored-by: Connor Byrne <c.byrne@comfy.org>
…st-run tour (#15173) ## Summary `handleStartupOutcome` treated "not a tour candidate on this boot" as "already onboarded", permanently writing `Comfy.TutorialCompleted` for users who were only transiently ineligible. ## Changes - **What**: `isFirstRunCandidate()` returns false for five reasons, only one of which is stable. `handleStartupOutcome` marked the tutorial completed for all five. `Comfy.TutorialCompleted` is persisted server-side against the user record and is only ever set to `true`, so a single ineligible boot removed onboarding from that account forever. Replaced the boolean with a three-way decision: `complete` (mark + template browser), `defer` (template browser only, flag untouched), `getting-started`. `isFirstRunCandidate()` is now derived from it, so `handleUrlWorkflow` is unchanged. Classification: | condition | decision | why | | -------------------------- | -------- | --------------------------------------------------------------------------------- | | `!isCloud` | complete | build-time `__DISTRIBUTION__`; cannot change for this deployment | | `isNewUser() === false` | complete | a determined returning user does not become new again | | `!onboardingTourEnabled` | defer | server flag, defaults false before `/features` resolves, and flips during rollout | | `!isDesktopWidth` | defer | viewport | | `!isSubscriptionEnabled()` | defer | reads `window.__CONFIG__`, written by the same `/features` fetch | | `isNewUser() === null` | defer | undetermined is not a determination | Two reachable cases this fixes. Signing up on a phone and returning on a laptop is ordinary behaviour, and today it costs the user onboarding permanently — raised by @MaanilVerma on #15091. The broader variant, found while verifying that one: every boot taken while `onboarding_tour_enabled` is off marks _every_ new user completed, so the entire cohort onboarded before the rollout can never see the tour once it is turned on. ## Review Focus `isSubscriptionEnabled()` is `isCloud && window.__CONFIG__?.subscription_required` — deployment config, not per-user subscription state, so "permanent" is arguable. It is classified transient because `window.__CONFIG__` is populated by the async `/features` fetch in `refreshRemoteConfig`, which sets it to `{}` on timeout (5s), on 401/403, and on any network error. A wedged features endpoint would otherwise burn the tour for every user who booted during the outage. The cost of being wrong is asymmetric: a wrong `defer` reopens the template browser one extra time, a wrong `complete` is unrecoverable. The `url-intent` branch still marks completed, unchanged. That user got a real first-run experience — their workflow loaded, and `handleUrlWorkflow` offers the tour over it — so it is a genuine completion, not an environmental miss. Candidacy is still read once per startup: `decideFirstRun()` is called a single time in `handleStartupOutcome`, so a later resize, flag refresh, or subscription change cannot unmount the Getting Started screen mid-interaction. Covered by the existing test. Non-candidates still get `Comfy.BrowseTemplates` on both paths. ## Tests Existing disqualifier table split into permanent and transient. Four new transient cases assert the flag is not written, plus an end-to-end case that runs two boots through a `setSetting` mock that actually persists: narrow viewport, then desktop. All five fail on `main` (`expected "vi.fn()" to not be called at all, but actually been called 1 times`, and `expected false to be true` for the two-boot case). Co-authored-by: Connor Byrne <c.byrne@comfy.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )