## Summary
Backport outputs from new cloud history endpoint
Does:
1. Show history in the Queue
2. Show outputs from prompt execution
Does not:
1. Handle appending latest images generated to queue history
2. Making sure that workflow data from images is available from load
(requires additional API call to fetch)
Most of this PR is:
1. Test fixtures (truncated workflow to test).
2. The service worker so I could verify my changes locally.
## Changes
- Add `history_v2` to `history` adapter
- Add tests for mapping
- Do branded validation for promptIds (suggestion from @DrJKL)
- Create a dev environment service worker so we can view cloud hosted
images in development.
## Review Focus
1. Is the dev-only service work the right way to do it? It was the
easiest I could think of.
4. Are the validation changes too heavy? I can rip them out if needed.
## Screenshots 🎃https://github.com/user-attachments/assets/1787485a-8d27-4abe-abc8-cf133c1a52aa
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6288-Feat-history-v2-outputs-2976d73d365081a99864c40343449dcd)
by [Unito](https://www.unito.io)
---------
Co-authored-by: bymyself <cbyrne@comfy.org>
## Summary
Added Service Worker to inject Firebase auth headers into browser-native
`/api/view` requests (img, video, audio tags) for cloud distribution.
## Changes
- **What**: Implemented [Service
Worker](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API)
to intercept and authenticate media requests that cannot natively send
custom headers
- **Dependencies**: None (uses native Service Worker API)
## Implementation Details
**Tree-shaking**: Uses compile-time `isCloud` constant - completely
removed from localhost/desktop builds (verified via bundle analysis).
Verify yourself by building the app and `grep -r
"registerAuthServiceWorker\|setupAuth" dist/`
**Caching**: 50-minute auth header cache with automatic invalidation on
login/logout to prevent redundant token fetches.
**Message Flow**:
```mermaid
sequenceDiagram
participant IMG as Browser
participant SW as Service Worker
participant MT as Main Thread
participant FB as Firebase Auth
IMG->>SW: GET /api/view/image.png
SW->>SW: Check cache (50min TTL)
alt Cache miss
SW->>MT: REQUEST_AUTH_HEADER
MT->>FB: getAuthHeader()
FB-->>MT: Bearer token
MT-->>SW: AUTH_HEADER_RESPONSE
SW->>SW: Cache token
end
SW->>IMG: Fetch with Authorization header
Note over SW,MT: On login/logout: INVALIDATE_AUTH_HEADER
```
## Review Focus
- **Same-origin mode**: Service Worker uses `mode: 'same-origin'` to
allow custom headers (browser-native requests default to `no-cors` which
strips headers)
- **Request deduplication**: Prevents concurrent auth header requests
from timing out
- **Build verification**: Confirm `register-*.js` absent in localhost
builds, present (~3.2KB) in cloud builds
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6139-auth-add-service-worker-on-cloud-distribution-to-attach-auth-header-to-browser-native--2916d73d3650812698dccd07d943ab3c)
by [Unito](https://www.unito.io)
Summary
- Adds playwright.config.ts and playwright.i18n.config.ts to
typescript-eslint projectService.allowDefaultProject in
eslint.config.ts.
Why
- Pre-commit runs lint-staged, which lints staged TypeScript files
including Playwright config files.
- These configs are not included in any tsconfig, so typescript-eslint’s
project service can’t find a project and fails with:
"Parsing error: .../playwright.config.ts was not found by the project
service. Consider either including it in the tsconfig.json or including
it in allowDefaultProject".
What this changes
- Whitelists the two Playwright config files to use the default project
(isolated file parsing) so ESLint can parse and lint them without being
part of a tsconfig.
- Does not affect application code linting, which remains fully
type-aware via existing tsconfigs.
Alternatives considered
- Include these configs in a dedicated ESLint tsconfig (e.g.,
tsconfig.eslint.json) and point ESLint to it.
- Exclude Playwright config files from lint-staged (would reduce lint
coverage for them).
- Keep as TypeScript but non-type-aware: current approach is minimal and
avoids touching tsconfig scopes.
Verification
- Reproduced pre-commit failure when changing playwright.config.ts.
- After this change, `pnpm exec eslint --cache --fix
playwright.config.ts` succeeds.
- `pnpm typecheck` passes.
Notes
- No changes to Playwright runtime behavior. This only affects linting.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5901-chore-eslint-allow-default-project-for-Playwright-configs-to-fix-pre-commit-linting-2816d73d36508156b94dfeff79a91c7f)
by [Unito](https://www.unito.io)
## Summary
Extracts ComfyUI registry types into a dedicated workspace package for
better modularity.
## Changes
- **What**: Created `@comfyorg/registry-types` package to house
generated type definitions
- **Breaking**: None - maintains backward compatibility through
re-exports at original path
- **Dependencies**: Added `@comfyorg/registry-types` as workspace
dependency
## Review Focus
Is this the right granularity for package extraction, or should registry
types be part of a larger shared package?
PR split into two tiny diffs:
- [Part
one](f8d3d2fa01)
- [Part
two](f8d3d2fa01..c48ca84336)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5840-Extract-registry-types-into-workspace-package-27c6d73d365081dbb824d680ce739316)
by [Unito](https://www.unito.io)
## Summary
Enforced test file naming conventions with ESLint rules and renamed 26
test files from `.spec.ts` to `.test.ts`.
## Changes
- **What**: Added ESLint rules to enforce `.spec.ts` files only in
`browser_tests/tests/` and `.test.ts` files only in `src/`
- **What**: Renamed 26 component/unit test files from `.spec.ts` to
`.test.ts` to comply with new convention
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5820-enforce-test-file-naming-rule-27b6d73d365081269b32ddcc9d3a5048)
by [Unito](https://www.unito.io)
## Summary
- Added missing directories and files to tsconfig.json to ensure
complete TypeScript type checking coverage
- Expanded config file patterns to include all .mts configuration files
- Verified all 908 TypeScript files in the project are now properly
covered
## Changes
- Added `scripts/**/*.ts` to cover all TypeScript files in scripts
directory (i18n collection, CI/CD scripts)
- Added `build/**/*.ts` to cover customIconCollection.ts and future
build scripts
- Changed `vite.config.mts` to `*.config.mts` to include all vite config
files (vite.electron.config.mts, vite.types.config.mts)
## Test plan
- [x] Run `pnpm typecheck` to verify no TypeScript errors
- [x] Verified all TypeScript files are covered by tsconfig patterns
- [x] browser_tests/ directory confirmed to have its own extending
tsconfig
🤖 Generated with [Claude Code](https://claude.ai/code)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5655-chore-tsconfig-ensure-complete-TypeScript-coverage-for-all-project-files-2736d73d36508103acbadc53ca2b2913)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Alexander Brown <drjkl@comfy.org>
Co-authored-by: filtered <176114999+webfiltered@users.noreply.github.com>
## Summary
Don't route events up through GraphCanvas if the component itself can
handle the changes
## Changes
- **What**: Reduce the indirect access or action dispatch to
composables/stores.
## Review Focus
The behavior should be either equivalent or a little snappier than
before. Also, the local state in LGraphNode has (almost) all been
removed in favor of reacting to the nodeData prop.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5709-Refactor-Let-LGraphNode-handle-more-events-itself-2756d73d365081e6a88ce6241bceecc0)
by [Unito](https://www.unito.io)
---------
Co-authored-by: GitHub Action <action@github.com>
## Summary
Prerequisite refactor/cleanup to use a global store instead of having
nodes throw up events to a parent component that stores a reference to a
singleton service that itself bootstraps and synchronizes with a
separate service to maintain a partially reactive but not fully reactive
set of states that describe some but not all aspects of the nodes on
either the litegraph, the vue side, or both.
## Changes
- **What**: Refactoring, the behavior should not change.
- **Dependencies**: A type utility to help with Vue component props
## Review Focus
Is there something about the current structure that this could affect
that would not be caught by our tests or using the application?
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5695-Refactor-Composable-disentangling-2746d73d365081e6938ce656932f3e36)
by [Unito](https://www.unito.io)
