Repository navigation
Bug: Resolve lifecycle and execution through the selected engine connection #127
Description
Activity
- added 4 commits that reference this issue
on Oct 6, 2026 Issue #127 Completed ✅
The frontend integration for engine connection routing has been successfully implemented and merged into dev.
Implementation Summary
Frontend Changes:
- Added
connection_idfield toCreativeActionRequestandGenerationProvenanceTypeScript interfaces - Updated creative store with stable connection ID support and legacy engine_id mapping
- Implemented automatic ID conversion (managed_comfyui → comfyui-managed, managed_webui → webui-managed)
- Updated engine store to include connection_id in instances with ownership-based lifecycle control
- Modified lifecycle controls to route by engine type and prevent external engine control
- Updated CreationDock UI to use connection_id in engine selection dropdown
- Added comprehensive test suite with 13 tests
Test Results
✅ Backend Tests: 9/9 connection routing tests passed (260 total backend tests passing)
✅ Frontend Tests: 13/13 new connection routing tests passed (41 total frontend tests passing)
✅ Rust Launcher Tests: All tests passed
✅ All CI checks passedValidation
- Connection ID mapping validated for both ComfyUI and WebUI
- Creative action requests correctly include both connection_id and engine_id for backward compatibility
- Lifecycle controls properly route to type-specific endpoints
- External (non-managed) engines correctly prevented from lifecycle operations
- Connection registry compatibility confirmed with backend API
Merged PR
PR #161 merged into dev as commit 50b0ece
Live Testing Limitations
Full end-to-end testing requires running backend server with live engine instances. Unit and integration tests validate the routing logic and API contracts.
- Added
Summary
Creative runners use default ComfyUI/WebUI clients instead of resolving the chosen registry connection. Frontend lifecycle dispatch often chooses by engine type rather than managed/external identity. EmbeddedEngineView.tsx:29 reconstructs a localhost URL from a port, ignoring the configured host, protocol, and path. Both WebUI start callbacks in App use the Comfy runtime toggle.
Environment and evidence
devat c1c5dbe. The remotedevmatched this commit when filing.Reproduction or validation
Trace an external engine ID through frontend start/stop, creative execution, and EmbeddedEngineView. Frontend lifecycle selects managed routes by type, runners use default clients, the embedded URL is reconstructed from localhost/port, and WebUI start callbacks in App use the Comfy toggle. Validate with two mocked endpoints and assert the chosen connection receives the request.
User impact
The visible connection can differ from the engine receiving work or a start request.
Proposed approach
Carry one stable connection ID end to end; use its endpoint, capabilities, ownership, and lifecycle policy without type-based fallback.
Acceptance criteria
Additional source references
Related work
Related closed issue: #72. This follows up connection identity/endpoint propagation beyond the earlier fixed port literals.
Verification scope
Real GPU inference, paid-provider compatibility, and a clean-machine packaged desktop journey remain unverified. Any follow-up implementation should target
devunder the repository's contribution/branching rules.