ttulttul-ComfyUI-Modal/docs/LEARNINGS.md

Learnings

2026-06-22

• ComfyUI's Dependency cycle detected message can originate entirely in the local scheduler after Modal-Sync rewrites remote nodes into proxy phases, even when the Modal worker and individual remote sampler components finish successfully. The local queue path now logs compact rewritten-prompt diagnostics, including proxy dependency edges, component stages, payload summaries, and any static cycle path, so the next UI-only cycle error can be traced from comfy.log without guessing which remote phase was responsible.
• Split-proxy phase ordering cannot consider only the remote component's internal links. A local feedback path such as remote sampler A -> VAEDecode -> BetterGrok -> remote sampler B is still a dependency from A to B when B's boundary input re-enters the remote island, and ignoring that path can make B produce shared model bridge outputs that A then depends on, creating a proxy-level cycle that the original workflow UI did not show.
• Local preview branches are not the same as local feedback. If a remote output also feeds later remote work, and the local branch downstream from that output never reaches another remote node, the planner can absorb that local branch as a non-returning tap and keep the remote sampler chain in one component instead of splitting at every preview.
• Absorbing a preview tap means closing over its non-transportable boundary in both directions. A local VAEDecode preview branch cannot be moved remote while leaving its VAELoader local, and once that loader is remote, any remaining local VAEEncode or VAEDecode consumers of the same VAE must join the component too; otherwise the planner just moves the illegal VAE boundary from remote input to remote output.
• Preview taps should suppress split proxies only when the final component has no local re-entry dependency. If a component output feeds a local node such as BetterGrok and that local node feeds back into the same remote component, a single proxy creates a synthetic proxy -> local -> same proxy dependency cycle, so the component still has to split into ordered phases.
• Durable session bridge replay is acceptable for cheap loader/encoder recovery paths, but replaying a sampler bridge is usually a planning or affinity failure. When a downstream phase loses the live or warm bridge value for a sampler-producing component, the runtime now fails loudly instead of silently rerunning that sampler phase.
• Modal ExecutionError is used for both lookup/deployment failures and real remote runtime failures. Auto-deploy recovery must not key only on broad strings like not found, and both the stale-handle retry layer and the outer deployed-invocation catch need the same check; if the message contains a remote traceback or RemoteSubgraphExecutionError, surface the remote failure directly instead of importing the cloud deploy module and replacing the real error with an existing-app guard.
• Refocus replay cannot depend only on buffered Modal websocket events. Native ComfyUI completion events such as execution_success may be missed while the browser is backgrounded, so the frontend now reconciles temporary Modal UI state against ComfyUI's /queue and /history/{prompt_id} endpoints before leaving old node colors or the global pill visible.

2026-05-20

• The Modal status pill should be driven by actual remote work, not by the custom node route being installed. Since the frontend patches every prompt through /modal/queue_prompt, the backend must fast-path prompts with zero Run on Modal nodes without emitting modal_status, and the frontend should ignore any empty Modal status event as a defensive guard.
• A visibility/focus redraw is not enough if the browser missed Modal websocket events while backgrounded. The local ComfyUI side needs to retain recent client-scoped modal_status and modal_progress payloads, and the frontend should replay that buffer on refocus before redrawing the status pill and node overlays.
• Programmatic context-menu changes to properties.is_modal_remote also have to update the live Run on Modal widget value. Otherwise the saved workflow state and node border can be correct while the visible toggle still appears disabled.
• Graph-wide Modal enablement should operate on live eligible nodes, not just serialized workflow JSON. Scanning the root graph plus nested subgraphs lets the action update both node properties and visible widgets in one pass.
• Once Modal has several node context actions, putting them under one Modal submenu keeps labels short and prevents repeated prefixes from cluttering the main node menu.

2026-04-23

• Nested workflow-marker resolution has to stop at the first matching composed prompt-id suffix, not union every suffix. If a subgraph node 195:27 is marked remote and the prompt also contains an unrelated root node 27, collecting both matches makes the real nested node look local during boundary validation and proxy rewrite.
• Frontend interruption cleanup has to key off prompt_id, not the native execution event's node fields. ComfyUI can emit execution_interrupted without a representative remote node id, and if Modal UI teardown depends on resolving that node the cancelled prompt stays visually stuck in ready/active state even though interrupt propagation worked.
• The global Modal status pill cannot infer liveness from STATE_COMPLETE remote node states. If a prompt-level cleanup event is delayed or missing, treating completed remote nodes as still "executing" leaves stale waiting/executing/finalizing pill entries behind. The pill needs an explicit "does this prompt still have live remote work?" reconciliation pass when remote nodes complete.

2026-04-22

• Prompt-scoped Modal class parameters are the wrong place to carry remote session identity. The remote_session.session_id belongs in the payload for data isolation, but @app.cls affinity should use reusable worker-pool slots like worker-pool:slot:N; otherwise every prompt asks Modal for a brand-new parameterized class instance and cross-prompt warm-container reuse never happens.
• The local custom_nodes/ tree is effectively process-static for one ComfyUI lifetime. Since adding or removing custom nodes still requires a ComfyUI restart before node availability changes, the queue-time sync engine should resolve custom_nodes/ once per process and then reuse that cached decision instead of rehashing or rescanning the tree on every workflow run.
• Modal image builds snapshot local directories and fail if included files change during the build. ComfyUI writes under .cache/, including .cache/strings, while a local server is active, so the ComfyUI image include filter must treat that cache as volatile build input and exclude it.
• Warm bridge restoration is only half of the mapped seed optimization. Once every exported static bridge output has already been restored into the target remote session without replay, the seed payload should skip prompt_executor_execute entirely and synthesize its bridge-ref outputs directly from session state; otherwise the system still wastes seconds rerunning loader and encoder nodes after the expensive work was already avoided.
• Modal function snapshots are initialization snapshots, not mid-request checkpoints. The practical way to hide first-request model loads is to detect root literal loader nodes in the rewritten prompt, then execute them as synthetic one-node subgraphs during proactive warmup so the worker-local loader cache is hot before the real payload arrives.

2026-04-21

• Modal @app.cls class parameters are sensitive to postponed annotations. If a Modal entry module uses from __future__ import annotations, then a declaration like snapshot_profile_key: str = modal.parameter(...) reaches Modal as the literal string "str" at import time and class construction can crash before any request runs. Keep real annotations on the Modal entry classes, or quote only the non-Modal forward references instead.
• Durable bridge refs still are not enough on their own for fast repeat mapped runs. If the worker already has the live remote-only value in memory, the cheapest path is to cache that value by bridge_key and restore it directly into the next prompt-scoped session instead of replaying the whole static producer subgraph just to recreate the same MODEL or CONDITIONING.
• MODEL needs a different durable restore path from CONDITIONING. The practical shape is a self-contained node rehydration plan: if the producer node's inputs are all literals, the bridge record can rebuild just that loader node output and skip replaying the whole static phase. Pairing that with warm loader-cache coverage for checkpoint loaders turns repeat model restoration into a single-node rebuild instead of a multi-node prompt replay.
• Replay optimization needs its own instrumentation. A single mapped-phase summary that breaks bridge resolution down into live-session hits, warm bridge-cache hits, durable-record lookup time, replay time, session-restore writes, and loader-cache hit/miss deltas makes it obvious whether a repeat run really skipped work or just hid it behind another internal phase.
• Remote custom-node reuse is mostly an idempotence problem, not a raw import-speed problem. Once one extracted bundle root has already been initialized on a warm worker, repeating init_external_custom_nodes() for the same root mostly adds log noise and risk, so the runtime should treat that root as already loaded and make the reuse explicit in logs.
• The local streamed Modal bridge should stop waiting once it receives the terminal result envelope. In real runs, the underlying remote_gen(...) iterator can take tens of extra seconds to unwind after the remote payload has already finished, and that tail latency blocks mapped cleanup and makes one lane look like a straggler even though inference is done.
• Queue-time warmup estimates are not enough for mapped fan-out because the real list length is often only known when ModalMapInput executes. Registering the local map node as a warmup trigger lets Modal-Sync top up exact container demand one node earlier than the mapped proxy, and a short bounded head-start on those in-flight warmup slots is enough to overlap some cold boot time instead of discovering it only at the first seed call.
• custom_nodes/ behaves much better as a manifest plus per-package archives than as one whole-tree ZIP. The overall manifest still gives one deterministic tree digest for volume reload and runtime cache identity, but hashing and packaging each top-level custom-node package separately means one edited package no longer forces a full rebuild and reupload of every other unchanged package.
• Split custom-node archives only pay off if the local pipeline is parallel too. Building each per-package ZIP and uploading it independently in worker threads lets the local machine overlap the mostly I/O-bound file reads, compression, and Modal volume transfers instead of serializing those stages back into one long queue.
• Parallel local packaging needs a stricter policy on the Modal volume side than on the filesystem side. Metadata probes like VolumeListFiles can rate-limit well before the actual uploads do, so the safe pattern is to keep a small fixed concurrency for volume SDK calls and publish one shared exponential backoff window across all local workers when any of them gets ResourceExhaustedError.

2026-04-20

• Early local delivery for hybrid remote components is much simpler if the queue-time rewrite stops pretending the whole island is one proxy. Splitting the island into a static proxy and a mapped proxy lets ComfyUI unblock ordinary downstream local nodes using its existing scheduler semantics instead of inventing partial-completion behavior for one proxy node.
• The bridge between those split proxies cannot be a normal transport value when the shared upstream output is something like MODEL. The workable shape is an opaque session-ref payload: the static proxy returns a JSON-safe reference, the remote runtime stores the live object in a prompt-scoped session, and the mapped proxy resolves that ref back into the live object when it runs.
• A pure in-memory session ref is not enough once Modal can reroute later split phases onto a fresh container. The durable fix is a hybrid bridge: keep the fast path in the in-memory session store, but also persist replay metadata for each session-backed output in a separate Modal Dict so a later phase can rebuild the live remote-only value into its current session instead of failing on a dead ref.
• Session-backed split proxies can be local-cache-safe after all, but only if their exported bridge outputs are durable replay refs rather than prompt-scoped session ids. Once the proxy cache surface strips prompt_id, remote_session, and clear_remote_session, ComfyUI can reuse cached proxy outputs across prompt runs and the remote runtime can rehydrate any still-needed remote-only state lazily from the durable bridge metadata.
• Cache-safe stripping for session-backed proxies needs one more escape hatch in real ComfyUI runs: hidden unique_id is not guaranteed to come back on every execution path. Embedding a stable proxy-cache context id in the sanitized payload makes execution-payload rehydration robust even when the hidden field is absent.
• Every synthesized split-phase payload has to carry remote_session, not just the top-level hybrid payload. If a static or mapped phase builder drops that field, the remote worker only discovers the mistake at boundary-output collection time when it tries to export a session-backed output.
• Rewriting a component into multiple proxies means the old queue-time dependency metadata is stale. Execution stages, dependency edges, and partial-target remapping all need to be derived from the final rewritten proxy graph, not from the pre-rewrite coarse component plan.
• Prompt-scoped remote state is only useful if both halves of the split can reach the same worker. The current implementation now passes a reusable worker-pool affinity key into deployed RemoteEngine lookup, while the prompt-scoped remote_session.session_id stays inside the payload for data isolation.
• Online deployed testing confirmed the prompt-scoped session-affinity path for the tested hybrid workflow: the mapped proxy successfully reused the static proxy's remote-only state on the same worker instead of failing with a missing session/value-ref.
• The cheapest durable regression for this feature is a proxy-level scheduling test, not a full ComfyUI integration harness. If the rewrite produces separate static and mapped proxies, and a local downstream consumer can run off the static proxy result while the mapped proxy task is still awaiting completion, that already protects the core early-unblock behavior.
• It is still worth keeping one checked-in workflow-shaped artifact for this feature family. A JSON fixture that carries both the saved workflow metadata and the queued prompt shape catches rewrite drift that pure unit tests can miss, especially around proxy ids, downstream rewiring, and shared session ids.
• Session observability is most useful when the store and the runtimes both log. Store-level logs explain create/reuse/resolve/cleanup semantics, while runtime-level logs tie those session ids back to concrete component executions and clear_remote_session boundaries.
• Modal's own modal container logs path is just a thin wrapper over the SDK's AppGetLogs stream, so local observability does not need a separate sidecar. The remote worker can surface its MODAL_TASK_ID in the existing streamed payload channel, and the local ComfyUI side can mirror that task's container logs directly into local stderr with a CLI fallback when the Python SDK is unavailable.
• In practice, the local Python SDK log stream can emit Modal client task-context warnings when called from ComfyUI's own worker threads. Preferring the modal container logs subprocess path avoids that noise while still preserving an SDK fallback for environments that only have the Python package installed.
• The hybrid split-proxy pattern is useful beyond ModalMapInput. If a coarse remote component has several execute branches that only share a remote-only upstream value like MODEL, rewriting that component into ordered ordinary subgraph proxies gives ComfyUI real early completion points without needing partial-result semantics inside one proxy.

2026-04-19

• Early local unblocking is currently limited by the proxy shape, not just by transportable boundary types. If queue-time rewrite packs a remote branch into one hybrid mapped_subgraph proxy, static outputs that are already finished still cannot drive downstream local nodes until the mapped phase also finishes, because the remote runtime only merges and returns those outputs once at the end. Fixing that needs either partial-completion semantics for one proxy node or a shared remote session/cache that lets separate proxies reuse non-transportable state like MODEL.
• Mapped remote execution cannot hoist invariant upstream work safely by caching {prompt_id}:{node_id} outputs or by replaying per-item subgraph RPCs. The queue-time rewrite has to split the component into explicit static and mapped phase prompts, expose static-to-mapped boundaries, and let one runtime invocation execute both phases so non-transportable objects like MODEL stay in-process while PromptExecutor still decides reuse from effective inputs and dependencies.
• The frontend cannot treat mapped execution like a prompt-wide single active node. Per-lane progress is the durable source of truth there: ordinary non-mapped runs can still use activeNodeId, but mapped remote styling should derive purple/active state from whichever nodes currently hold live lane or numeric progress, and lane ownership needs to move when one worker advances from node A to node B.
• The test bootstrap should not hard-code ~/git/ComfyUI as its only source of ComfyUI imports. Reading COMFYUI_ROOT first makes it easy to validate the extension against a disposable checkout in /tmp while preserving the old local-default behavior.
• A usable uv test environment for this repo needs more than pytest. Importing current ComfyUI APIs during tests also requires aiohttp, Pillow, torch, safetensors, numpy, and tqdm, so those belong in the dedicated test dependency group instead of being installed ad hoc on one machine.
• On this host, uv sync worked reliably with UV_PROJECT_ENVIRONMENT and UV_CACHE_DIR=/tmp/uv-cache, but uv run ... crashed inside the installed uv binary with a macOS system-configuration panic. The environment itself was still valid, and invoking /tmp/.../bin/python -m pytest against that uv-managed environment was a workable fallback.

2026-04-18

• The README had drifted into release-note territory, especially in the old Important distinction: block. For this project, the maintainable structure is: short overview, explicit local-vs-remote execution sections, concise operational caveats, and a separate learnings log for historical implementation details.
• ComfyUI registry setup is mostly metadata, not code. The repo needs a real [tool.comfy] block in pyproject.toml, a stable immutable node-pack id, repository URLs, and an optional GitHub publish workflow; choosing a software license should stay explicit instead of being guessed during packaging work.
• comfy node pack is not git-aware by default; it uses .gitignore as its practical packaging filter. For a clean registry artifact, this repo needs an allowlist-style .gitignore so untracked local files like logs, caches, virtualenvs, and scratch docs cannot leak into node.zip.
• Remote per-node phase events are not enough to mirror sampler progress in the local UI. The Modal worker also needs a headless equivalent of ComfyUI's global progress hook so ProgressBar updates feed progress_state, and the local relay should forward those numeric updates as a separate high-frequency UI event rather than overloading coarse execution-phase messages.
• ComfyUI prompt cancellation does not need a separate frontend API hook to reach Modal. The proxy node can watch ComfyUI's existing processing_interrupted() flag while it waits on the remote call, send one targeted remote interrupt for the active (prompt_id, component_id), and then re-raise ComfyUI's own InterruptProcessingException so the local executor reports a normal execution_interrupted.
• That cancellation watch cannot live only in the outer proxy wrapper. The blocking Modal request bridge, especially the streamed remote_gen(...) path, also has to poll processing_interrupted() itself and set the per-request cancellation event before it asks Modal to stop; otherwise a locally cancelled prompt can unwind while the remote container keeps running.
• On the Modal side, targeted interrupt delivery cannot depend on a second RPC into the same GPU execution class. The earlier interrupt_payload lane only worked by reserving extra class concurrency, which fights horizontal scale-out. The better design is a shared control store that running executions poll while the GPU class itself stays at @modal.concurrent(max_inputs=1). Older allow_concurrent_inputs class options now hard-fail on current Modal SDKs.
• To let ComfyUI overlap multiple ready remote components, the proxy node itself has to be async. Merely increasing Modal-side concurrency is not enough if the local proxy still blocks inside a synchronous execute(), because ComfyUI's scheduler only uses its pending-task overlap path for async nodes.
• There are two separate local bottlenecks to remove for remote overlap: the proxy node must await remote work instead of blocking the scheduler, and the helper that submits blocking Modal SDK calls must use more than one worker thread or the local process will still serialize every remote invocation even after the proxy becomes async.
• Horizontal Modal scale-out needs a different concurrency model from interrupt delivery. If one GPU container should run only one heavy Comfy workflow at a time, cancellation can no longer depend on a second RPC lane into the same class; the clean fix is a shared control store such as a Modal Dict, with each execution polling its own cancel flag while max_inputs stays at 1.
• Data-parallel batching fits this architecture best as a queue-time marker plus a local scheduler, not as a magical runtime pass-through node. A ModalMapInput marker can stay inside the rewritten remote component, the proxy can split one boundary input locally into per-item subgraph calls, and the remote runtime can stay unaware because each item is still an ordinary subgraph execution.
• A single undirected "remote island" is too coarse once transportable values can cross remote-to-remote boundaries. The rewrite step should only force nodes together across non-transportable edges like MODEL or CONDITIONING, then topologically order the remaining transport-aware components from upstream to downstream so later proxies can safely wire themselves against earlier proxies.
• ModalMapInput changes the partitioning rule in one important way: the whole downstream remote region reachable from that marker should stay inside one mapped component, even across otherwise transportable edges. Without that exception, the marker would only map the first transport-aware slice of the workflow instead of the downstream region the user intended.
• That first transport-aware split is still only a coarse partition. Even when the original prompt is a DAG, the quotient between coarse groups can become cyclic after you merge only selected edges. Before rewriting proxies, the backend has to collapse strongly connected coarse groups back together or ComfyUI can later see a synthetic dependency cycle.
• Streaming intermediate remote UI outputs back into local ComfyUI is safest when it reuses ComfyUI's native websocket event shapes. Forwarding remote executed payloads and preview-image frames through the local PromptServer gives the browser real mid-run previews without pretending those inner remote node values are now available as local graph inputs.
• A downstream local PreviewImage node is a different problem from a remote node that already emits UI output. If a remote boundary IMAGE feeds a local preview node, the useful fix is to remember that direct preview consumer during prompt rewrite, stream the boundary tensor as soon as the remote source node finishes, and synthesize the local preview node's executed UI payload on the local side. That improves preview UX without trying to make ComfyUI execute arbitrary downstream local nodes incrementally.
• Queue-time remote-boundary fixes should come from the backend's actual rewrite logic, not from parsing error text in the browser. A small dry-run analysis route can reuse the same prompt-id resolution and upstream auto-expansion rules, then return workflow-node paths for the frontend to mark directly from a context-menu action, including nested subgraph nodes.
• For ComfyUI node right-click menus, patch getExtraMenuOptions at node-definition time in beforeRegisterNodeDef, not per-instance in nodeCreated. The prototype-level hook matches how working extensions inject menu entries and avoids menu items silently disappearing even when other per-node UI changes still show up.

2026-04-17

• The workflow metadata already rides along in extra_data.extra_pnginfo.workflow, so the backend can discover node.properties.is_modal_remote without any extra frontend metadata channel.
• That workflow metadata is not always flat. ComfyUI can embed saved node records inside nested subgraph fragments, so Modal marker discovery has to recurse through workflow JSON instead of only scanning the top-level workflow["nodes"] list.
• Nested saved subgraph ids are not necessarily queued prompt ids. Before rewrite-time graph traversal, nested Modal markers need to be resolved against the queued prompt id space: sometimes that means a composed id like 24:23, and when ComfyUI does not expose the inner node directly it means falling back to the nearest ancestor prompt node. Without that resolution step, the backend will crash trying to rewrite a saved workflow id that does not exist in the actual prompt.
• A single wildcard-output proxy node is not enough for server-side graph rewriting. ComfyUI validates downstream link indices and output arity against the replacement class, so the backend has to generate proxy node classes that mirror the original node’s output signature before validation runs.
• Keeping the sync engine content-addressable makes prompt rewrites cheap after the first upload. The route can block on sync safely as long as repeated requests collapse to a hash marker check.
• Hashing and zipping the entire custom_nodes/ tree inside the queue route is too expensive for COMFY_MODAL_EXECUTION_MODE=local. Local mode should skip custom-node bundle sync by default, with an explicit override when that path needs to be exercised.
• When rewriting a prompt node into a proxy, never reuse the same input dict for both prompt_node["inputs"] and original_node_data["inputs"]. Inserting original_node_data back into the live prompt inputs creates a recursive structure that breaks ComfyUI cache signature hashing with a RecursionError.
• Queue-time validation is necessary for remote nodes that still receive local Comfy runtime objects. Even if a node is marked remote, inputs like MODEL or CONDITIONING cannot be serialized across the current boundary, so the prompt should be rejected before execution rather than failing inside the serializer.
• Per-node proxying is not enough for real ComfyUI sampler graphs. Connected remote-marked nodes must be partitioned into a single remote component so internal edges like MODEL, CLIP, and CONDITIONING stay inside the remote subgraph and only the true local/remote boundary has to be transport-safe.
• Manually marking every upstream dependency is too brittle for arbitrary custom nodes. A better default is to auto-expand the remote node set upstream across any non-transportable edge, so a user can mark the downstream custom node they care about and let the backend absorb the required loaders/builders into the same remote island automatically.
• The local fallback runtime cannot call PromptExecutor.execute() inline from inside a proxy node, because ComfyUI is already running inside an active asyncio loop. Running remote subgraph execution in a worker thread avoids nested-event-loop failures while still reusing ComfyUI’s executor.
• Modal objects defined in-process are not directly callable from an arbitrary long-running app like ComfyUI unless they are inside a hydrated app.run() session or looked up from a deployed app with modal.Cls.from_name(...). In practice the correct default for this project is deployed lookup only, because ephemeral app.run() fallback rebuilds too much state between workflow executions and undermines the scale-to-zero cost model.
• A deployed-only strategy is still correct, but the custom node should bootstrap that deployment itself on first use. The pragmatic flow is: try Cls.from_name(...), and if the app is missing, programmatically call app.deploy(...) from the stable cloud entry module, then retry the lookup.
• ComfyUI loads custom node packs from directories under synthetic module names derived from filesystem paths, and for directory-based packs that module key is not guaranteed to be a valid Python import path. Modal container startup requires a real importable module name for @app.cls services, so the cloud entrypoint has to live in a separate, stable module such as comfyui_modal_sync_cloud.py rather than on the custom-node package module itself.
• When the local side imports that stable cloud entrypoint for first-run auto-deploy, a failed import can poison sys.modules with a half-initialized module. The loader has to evict cached modules that do not expose a real deployable app, and it has to remove failed imports from sys.modules, or later auto-deploy attempts will keep reusing the broken stub.
• Shipping the ComfyUI source tree into the Modal image is not enough by itself. The container also needs ComfyUI's import-time Python dependencies such as psutil, aiohttp, einops, torchsde, torchvision, and related runtime packages, or the remote worker fails before it can execute any graph nodes.
• Core ComfyUI imports extend beyond the obvious tensor stack. In practice the Modal image also needs startup/runtime packages such as alembic, pydantic-settings, spandrel, and kornia, because built-in nodes and config-parsing paths import them before a workflow gets very far.
• Quantized ComfyUI models add another hard dependency: if comfy-kitchen is missing in the Modal image, comfy.quant_ops.get_layout_class(...) falls back to None and FP8/FP4 model loading eventually fails with 'NoneType' object has no attribute 'Params'.
• A captured "working workflow" exported after a remote run is not necessarily a pristine authoring graph. It can contain internal rewrite artifacts like ModalUniversalExecutor, so checked-in workflow JSON should be treated explicitly as a smoke fixture unless it has been normalized.
• When performance work starts, timestamped logging matters more than adding yet more ad hoc messages. Giving the extension its own formatter with both wall-clock time and relativeCreated makes it much easier to see whether the delay is in hashing, sync, deployment, image build, or actual execution.
• Once the slow path is visible, the first easy win is persistent local caching of digests and bundle artifacts. For this project, caching file hashes by (path, size, mtime_ns) and caching digest-keyed custom_nodes archives under the local storage root avoids re-reading huge model files and re-zipping the same custom_nodes tree on every execution.
• After the local side is fast, the next blind spot is inside the Modal container. The cloud runtime needs its own phase-timed logs around volume reload, runtime initialization, PromptExecutor execution, and output collection; otherwise the remote call just looks like one giant wall-clock block and there is no way to tell scheduling delay from real inference time.
• A dedicated Python logger is not always enough for those cloud timings. In practice, Modal container logs may still omit named-logger INFO lines during ComfyUI startup, so the timing tracer should mirror its phase lines directly to container stdout to guarantee they appear in captured remote logs.
• ComfyUI root discovery for deploy-time image building cannot rely only on ~/git/ComfyUI. When the extension is installed under ComfyUI/custom_nodes/ComfyUI-Modal, the most reliable default is to derive the ComfyUI root from that install path and only fall back to home-directory heuristics.
• If the remote image also contains ComfyUI's top-level custom_nodes/ tree, the container will import the full custom node set twice: once from the image and once from the extracted sync bundle. The image should ship ComfyUI core without custom_nodes/, and the synced bundle should be the single source of external nodes.
• ComfyUI still assumes that its default custom_nodes directory exists even if you do not want to populate it from the image. If that directory is missing, nodes.init_external_custom_nodes() can crash on os.listdir(...), so the remote runtime should create an empty placeholder directory before external-node initialization.
• Warm-container optimization is most effective when expensive but graph-agnostic work moves into @modal.enter. For this project that includes built-in ComfyUI runtime initialization and execution-module imports, so snapshots and scaledown-window reuse can amortize that startup cost across requests.
• On GPU-backed functions that only use CPU memory snapshots by default, @modal.enter(snap=True) must stay CUDA-safe. Snapshot-phase prewarm should only do CPU-only work there, and the heavier ComfyUI runtime initialization should move to @modal.enter(snap=False) unless GPU snapshots are explicitly enabled.
• If GPU memory snapshots are enabled, the snapshot-phase hook can safely pre-initialize more of ComfyUI core and capture that state. This repo now uses that split so the same code path benefits from either CPU-only snapshots or GPU snapshots without accidentally initializing CUDA in the wrong phase.
• Once warm-container runtime init is amortized, the next bottleneck is usually the graph's own loader nodes. For this repo, UNETLoader, CLIPLoader, and VAELoader are worth caching inside the warm container by resolved loader inputs, and cached outputs should be cloned when possible so later requests can reuse loaded runtime objects safely.
• Loader caches are only part of the story. Local ComfyUI keeps one long-lived PromptExecutor in the prompt worker, so ordinary node outputs stay cached across runs as long as their signatures do not change. A remote worker that creates a fresh PromptExecutor per request throws that benefit away, so it needs a warm-container executor pool keyed by cache scope to preserve ComfyUI-style node-output reuse between runs.
• End-to-end prompt_executor_execute timing is still too coarse once the denoising loop is only a small fraction of the total. A headless prompt server can observe executing and executed events from PromptExecutor and emit per-node spans, which exposes whether the real time is in model loaders, encoders, or the sampler itself.
• For repeat ComfyUI workflows, the highest-leverage lifecycle knob is usually not min_containers=1 but a longer scaledown_window with min_containers=0. That lets a recently used container keep its fully initialized ComfyUI process warm for a while without forcing permanent idle billing between totally unrelated runs.
• Floating pip install torch torchvision in the Modal image is too unstable once ComfyUI tracks very new PyTorch releases. The remote image should pin the same known-good CUDA wheel family as the local ComfyUI environment, and for this repo that means the explicit PyTorch CUDA 12.8 index with torch==2.10.0, torchvision==0.25.0, and torchaudio==2.10.0.
• The frontend can reuse ComfyUI's native executing, execution_error, and execution_success websocket events for remote component visuals as long as the queue route also publishes the representative-node-to-original-node mapping after rewrite. That keeps the UI in sync with actual proxy execution instead of inventing a separate polling channel.
• When filtering the ComfyUI checkout for the Modal image, only exclude top-level runtime asset directories like models/ and output/. A blanket "ignore any path part named models" rule will also delete real Python packages such as comfy/ldm/models, causing import failures inside the container.
• Importing nodes.py alone is not enough inside the Modal container. The remote worker also has to run nodes.init_extra_nodes(...) once so built-in comfy_extras nodes such as EmptyFlux2LatentImage exist in NODE_CLASS_MAPPINGS, and then run init_external_custom_nodes() for each extracted custom-node bundle root it exposes.
• A bare PromptExecutor(_NullPromptServer()) is not equivalent to real ComfyUI startup. The headless worker must pass the same cache configuration that main.py uses, or execution eventually crashes when the executor polls caches with self.cache_args["ram"].
• If /modal/queue_prompt does expensive preparatory work before it returns, the frontend can keep ComfyUI's own queue/execution indicators alive by dispatching temporary synthetic status, execution_start, and executing events, then letting the real websocket events take over once the prompt is actually queued.
• For remote node-level UI feedback, a streamed Modal generator method is cleaner than a side-channel file or volume poller. Yielding progress envelopes directly from the remote execution method lets the local client forward active-node updates into ComfyUI's websocket stream in real time without extra storage commits, reloads, or cleanup logic.
• Some custom-node packs register HTTP routes or prompt handlers at import time through PromptServer.instance. A headless remote worker still needs to provide a minimal PromptServer.instance shim with routes, app, supports, and no-op send methods, or those packs fail during external custom-node initialization before any workflow execution begins.
• For good remote UX, one generic "executing" node state is not enough. The frontend needs separate visual states for "setup", "ready in Modal", "currently executing remotely", "finished for this run", and "workflow fully done", with whole-workflow success clearing the temporary remote states back to the normal idle outline.
• The global Modal activity badge needs the same cleanup discipline as the per-node overlays. If a prompt entry survives in badge state after the prompt itself is gone, the UI can get stuck showing an orange "setup running" badge even though the workflow finished; pruning orphaned prompt ids fixes that.
• One orange badge state is not expressive enough. The frontend can use queue-time modal_status setup for "Syncing graph with Modal", then switch to a separate waiting state when the proxy begins executing but before the first streamed remote-node event arrives, which makes the remote lifecycle much easier to understand from the UI.
• Browser backgrounding can make the badge look stale even when the underlying prompt state already advanced. Deriving the global pill phase from live per-prompt node state, and refreshing it again on visibilitychange / focus, makes the pill recover promptly when the user returns to the tab.
• Subgraph-expanded prompt ids need UI aggregation just as much as backend marker resolution. If a streamed remote event targets 24:23, the visible outer subgraph node 24 should derive its phase from all descendant remote ids under that prefix; otherwise the outer node can stay stuck in setup even though the internal remote nodes are already running or complete.
• Warm-container caches and loader reuse can conflict with modal.Volume.reload(). If a request truly needs a fresh volume reload after uploading new assets, the worker may have to clear warm loader caches, drop reusable prompt executors, unload ComfyUI models, and retry the reload once to get past Modal's "open files preventing the operation" error.
• The synthetic frontend events have to match ComfyUI's websocket adapter shapes exactly, not just semantically. In practice that means status detail must be the inner status payload, executing detail should be the display node id string, and queue-list initialization state benefits from a matching "Waiting for a machine" notification payload keyed by prompt id.
• Even with correctly-shaped synthetic events, ComfyUI's built-in queue UI may still not present an obvious "workflow running" state during long pre-queue Modal setup. The extension should own a separate global activity badge so users have explicit feedback while the remote runtime is still being prepared.
• Synced asset paths cannot stay as abstract /assets/... markers inside the Modal worker. Remote execution needs those markers materialized to real absolute files under the mounted storage root, and ComfyUI's folder_paths helpers need an absolute-path fast path so loader nodes can still resolve them.
• A local filesystem mirror is not enough in COMFY_MODAL_EXECUTION_MODE=remote. Queue-time sync must upload assets into the actual named Modal volume via the local SDK, and the remote worker must call vol.reload() before execution so warm containers can see newly uploaded files.
• Once warm-container caches keep models and executors alive, unconditional vol.reload() becomes wrong: Modal can reject reloads while files from the mounted volume are still open. The queue side already knows whether a request actually uploaded anything new, so that fact should travel in the payload and only requests with fresh uploads should reload the mounted volume.
• Fast cancel-and-restart sequences can still race the container's file-handle cleanup even after warm caches are cleared. For the specific Modal "open files preventing the operation" reload failure, the remote worker needs a generous bounded retry window after cache/model cleanup rather than a single immediate retry.
• That queue-time requires_volume_reload bit is not enough once one logical request fans out into many per-item Modal calls. Mapped execution also needs a stable per-request reload marker so each warm container can reload the mounted volume once for that asset snapshot and skip the duplicate reloads from later mapped items.
• The reload marker also has to be request-wide across remote components, not minted separately per component payload. Otherwise a single workflow that rewrites into several remote chunks can still force repeated vol.reload() calls on the same warm container as it advances from one chunk to the next.
• Even after bounded retries, vol.reload() can still fail on a warm container that already has the right hashed assets visible on disk. In that case the worker should verify the payload's referenced mounted-volume paths and proceed when they are already present, rather than treating a redundant reload failure as fatal.
• ModalMapInput cannot blindly repeat every execute target in its coarse remote component. If a mapped branch shares a non-transportable upstream dependency with an unmapped remote sibling, the payload needs to separate one-time execute nodes from per-item execute nodes so the sibling branch still runs once while the mapped branch fans out per item.
• Mapped Modal fanout needs stable local worker lanes, not just a semaphore over one task per item. The UI can only render sensible concurrent progress if each in-flight mapped run carries a durable lane id; otherwise parallel item updates all target one node-progress slot and the bar flickers incoherently.
• Hybrid mapped components also need stream-level UI filtering. A warm PromptExecutor can still emit cached executed or preview UI events for static sibling nodes during per-item mapped runs, so the local relay has to drop any streamed UI event whose node id is outside the current mapped/static payload's execute and boundary-output node set.
• Modal proxy nodes that sit on a mapped boundary must opt into ComfyUI INPUT_IS_LIST semantics themselves. Otherwise ComfyUI can auto-map the proxy once per item before Modal-Sync sees the batch, which makes the entire hybrid component rerun per item instead of letting the internal mapped scheduler split only the intended branch.
• Once a proxy opts into INPUT_IS_LIST, ComfyUI also wraps the proxy's hidden payload input itself. The proxy has to unwrap singleton lists on original_node_data as well as ordinary kwargs, or it will reject valid rewritten payloads with a misleading "must be a mapping" error before remote execution even starts.
• Rewritten remote prompts need a last-mile canonicalization pass before execution. If a socket index leaks through as ["node", [0]], a scalar input arrives as [4], or an execute node id arrives as ["12"], ComfyUI's executor eventually crashes trying to treat the list like an integer or node id; normalizing those singleton wrappers on both the local and Modal-side runners avoids that failure mode.
• Once the easy wrapper shapes are normalized, the next debugging step should be structured worker-side diagnostics, not more blind guesses. Logging the normalized execute-node ids, boundary outputs, suspicious remaining wrapped prompt inputs, and the raw ComfyUI execution_error payload makes the surviving malformed field visible on the very next remote failure.
• Hybrid mapped components cannot hand the whole coarse component prompt to every sub-run. Even when a static sibling should execute once, PromptExecutor still validates the full prompt, so static and per-item sub-runs must prune the rewritten prompt to the dependency closure of their own execute_node_ids or the unrelated branch's batched inputs can still fail validation.
• That trim pass also has to tolerate stale execute ids that survive into a sub-run payload after rewrite. Dependency resolution should drop any execute target missing from the current trimmed prompt instead of assuming every listed node id still exists and crashing with KeyError.
• Prompt canonicalization also has to run on hydrated boundary inputs, not just on the stored subgraph prompt. Otherwise a proxied scalar boundary value like [4] can be spliced back into an INT socket unchanged and fail later inside PromptExecutor with int(list).
• A generic PromptExecutor failure string is not enough for debugging rewritten remote prompts. The worker should surface execution_error context like node_id, node_type, and current_inputs, and it should preflight primitive widget sockets for raw list literals before execution so the first visible error names the offending node/input/value instead of only reporting int(list).
• Modal's public Python SDK does not expose a direct "kill this @app.cls container" call from the local client. If we want crashy warm GPU workers to disappear immediately, the practical design is to have the local side opt into crash teardown and the remote worker schedule os._exit(1) on itself after surfacing the exception.
• Content-addressed sync should trust the deterministic payload path, not only the sidecar marker. If a crash happens after uploading a hash-named asset but before writing its .done marker, the next run should backfill the marker and reuse the existing payload instead of trying the same upload again and failing with FileExistsError.
• The streamed Modal generator path needs the same tensor-aware serialization rules as ordinary node input/output transport. If a progress or result envelope leaks a raw torch.Tensor, Modal's JSON encoding fails before the local client ever sees it, so the stream layer should normalize event payloads through the shared serializer too.
• Modal volume metadata calls can become a bottleneck on their own. Repeated VolumeListFiles checks for the same marker path are worth memoizing for the life of the queue request, and transient ResourceExhaustedError responses should be retried with backoff instead of surfacing immediately as hard prompt failures.
• Modal volumes are a poor fit for high-cardinality existence checks. For content-addressed uploads, the fast path should be a separate Modal Dict keyed by digest, with the volume reserved for the payload bytes themselves. That changes unchanged syncs from "many VolumeListFiles calls" into "a few metadata reads," and it avoids rebuilding a marker-file protocol on top of the volume API.
• A digest index is not enough by itself if the metadata store can outlive the underlying volume contents. The sync index needs a volume-epoch guard that is validated against the volume itself, otherwise a fresh or recreated volume can incorrectly reuse stale dict records for payloads that are no longer present.
• Modal first-run deploy needs a readiness phase, not just a deploy phase. app.deploy() returning does not guarantee that Cls.from_name(...) will succeed immediately from every caller, so concurrent warmup and payload threads should share one thread-safe "deploying -> lookup-ready" state and wait for lookup readiness instead of treating early lookup misses as grounds for a second deploy.
• Modal volume SDK calls should not run directly on the aiohttp request event loop. Running them in a worker thread avoids AsyncUsageWarning, and a missing path from Volume.listdir() should be treated as an ordinary "not uploaded yet" cache miss instead of a hard failure.
• The Modal container can pick up a non-package utils module before ComfyUI initializes. Preloading ComfyUI's own top-level utils package from the bundled source tree prevents utils.install_util import failures during init_extra_nodes(...).
• If the goal is "no idle billing, but no minute-long rebuild every run", the right Modal pattern is a deployed app with min_containers=0, not ephemeral app.run(). That lets Modal reuse the built image and deployed objects while still scaling compute down to zero between executions.
• Modal hardware selection belongs in deployment configuration, not in request payloads. For this repo, the remote class should read a configurable GPU string from environment at deploy time, and changing it later requires a redeploy or app recreation because existing deployed app hardware does not update in place.
• Modal memory snapshots only help once the app is deployed. They are a good default for CPU-side initialization work, while GPU memory snapshots should remain opt-in because Modal still labels them alpha and they may require additional runtime refactors.
• If the goal is faster cold restarts for heavyweight diffusion loaders, request-time warmup is not enough. The loader work has to move into @modal.enter(snap=True) behind a stable per-model-set snapshot profile, otherwise fresh workers will still pay one UNETLoader/CLIPLoader miss each even when GPU snapshots are enabled.
• That snapshot profile must also survive any split-payload rewriting. If static/mapped phase payload builders drop snapshot_profile_key, mapped worker lanes will look up the default RemoteEngine class and all the snapshot work will appear to do nothing in logs.
• Preserving snapshot_profile_key in split-phase helpers is still not enough if the key only exists as a transient local variable during deployed-class lookup. Once a coarse payload synthesizes a loader snapshot profile, that key has to be written back onto the payload itself so later mapped/static descendants inherit it instead of recomputing from a loader-free subgraph and falling back to snapshot_profile=None.
• Even that runtime-side coarse-payload writeback can still be too late when the queue rewrite has already materialized split proxy payloads. In that case the rewrite step itself must stamp the derived snapshot_profile_key onto the split payloads before they are inserted into the rewritten prompt.
• A payload carrying snapshot_profile_key is not sufficient by itself if the underlying snapshot-profile record has never been stored. Remote lookup should opportunistically store the record whenever it can still reconstruct the loader prewarm plan set, even if the payload already arrived with the key prefilled.
• GPU snapshots are not worth enabling blindly for generic no-profile workers. A snapshot_profile=None container that snapshots only “ComfyUI core initialized” state can still be unstable after restore and does not buy the model-loaded cold-start win we care about, so the safer policy is to reserve GPU snapshot prewarm for real loader-profile:... workers only.
• The same rule should apply to proactive warmup. If GPU snapshots are enabled but _build_prompt_warmup_request() cannot derive a loader profile, the scheduler should skip the ::warmup lookup entirely instead of instantiating a generic snapshot_profile=None class that cannot create a useful model-loaded snapshot.
• A seeded-lane scheduler should not impose a global seed barrier. Once each lane has its own stable bound worker, the highest-throughput policy is to let each lane await only its own seed:* phase and start mapped items immediately, otherwise one slow cold lane wastes GPU time on every other already-ready lane.
• Prompt completion also should not wait for every seeded lane task to return. If faster lanes already drained the mapped item queue, the scheduler can return immediately, clean up only the lanes that actually seeded, and let any extra slow lane finish booting in the background so it becomes a warm worker for the next prompt instead of blocking the current one.
• Modal snapshot identity should follow immutable cold-start state, not scheduler lane identity. If lane affinity is folded into the @app.cls parameters, Modal builds and caches one GPU snapshot per slot even when every lane loads the exact same ComfyUI runtime and model profile. Keeping only snapshot_profile_key and GPU-snapshot mode in the class parameters lets all lanes share the same expensive cold-start snapshot while lane assignment stays a local scheduling concern.
• Deployed Modal class behavior that matters at snap=True should not be inferred from environment inside the remote container. The container does not automatically inherit the local ComfyUI launch env, so flags like GPU-snapshot mode need to be carried as deploy-time/class parameters if the snapshot hook logic depends on them.
• A remote proxy cannot treat every incoming list literal as just another scalar boundary input. Ordinary remote components also have to preserve ComfyUI's implicit zipped batch semantics across the boundary, or primitive widget sockets like seed: INT end up receiving whole lists such as [10, 11, 12, 13] instead of per-item values.
• That implicit batching path also needs the same hybrid static-vs-mapped split as explicit ModalMapInput. If two remote execute nodes share a non-transportable upstream object like MODEL but only one of them depends on the multi-item boundary input, the sibling execute node still has to run once, not once per batch item.
• Suppressed per-item progress streams should not overwrite display_node_id with the component representative. Lane ids are enough to separate concurrent runs, so progress bars can stay attached to the actual executing node instead of collapsing onto the first node in the remote island.
• Placeholder lane-start updates are counterproductive for mapped progress. If the local scheduler paints a lane on the component representative node before any real node_progress event arrives, that ghost bar can outlive the later real-node updates and make the first node in the island look like it is still sampling.
• Aggregate batch-completion updates are a different kind of signal from real node progress. Reusing the same per-node rendering path for both makes ordinary remote nodes look like they emit sampler-style progress when they do not, so the frontend should treat aggregate mapped progress as global-only UI state.
• Aggregate mapped progress is still useful, just not as a fake node bar. The right presentation is UI that is explicitly batch-oriented: a shaded global status pill for overall completion and a small 3/16-style badge on the representative remote node.
• Prompt-wide UI state must not be rebuilt from one component's latest status event. Once the backend has published the full remote-component membership for a prompt, later per-component modal_status events should merge into that prompt metadata rather than shrinking it to whichever component happened to report most recently.
• ComfyUI progress_state payloads are not all true numeric progress. Upstream nodes can report trivial running states like value=0, max=1, and forwarding those verbatim makes loaders and text encoders sprout fake progress bars. The remote worker should treat only states with a meaningful progress range as node-local progress.
• Queue-time Modal setup is too long-lived to hide behind one generic "Syncing graph with Modal" label. The websocket status payload should be able to carry human-readable setup detail like packaging the custom-nodes ZIP, naming the asset currently uploading, and a short finalizing phase while the local side is still receiving remote outputs.
• Request-wide reload markers are useful for deduping vol.reload() across components, but the reload trigger itself should still be component-specific. If any uploaded asset in the workflow marks every component requires_volume_reload=True, warm containers end up retrying reload for components that never reference the fresh file.
• Reload diagnostics need to speak in terms of mounted-volume paths the payload actually references. Logging both the newly uploaded relevant paths and the broader referenced mounted-volume paths makes it much easier to see whether reload is being blocked by files the component truly needs or by stale warm-container handles from previous work.
• Ready/green is a prompt-acceptance state, not a per-component execution state. If the frontend waits for each proxy node's first executing event before marking nodes ready, most of the remote graph stays orange even after the rewritten prompt has already been accepted by Modal. The queue-success path should flip the whole remote prompt to ready immediately, while purple remains reserved for the currently active node.
• Websocket setup events are not guaranteed to land before the HTTP queue response resolves. If the queue-success path relies on prompt metadata that only arrived over websocket, backend-expanded upstream nodes can remain orange because the frontend only knows about the originally toggled workflow nodes. The accepted queue response should echo the resolved remote-node ids and component map so ready-state painting is deterministic.
• Component membership needs a reverse lookup as well as a representative lookup. Mapped progress and native ComfyUI execution events often arrive keyed to an ordinary node inside the remote island, and if the frontend can only expand representative ids it leaves the rest of that component stuck orange even though the island is already running.
• Streamed Modal node-progress events need to preserve the real executing node id even when ComfyUI also reports a display node id. Using only the display id collapses fan-out progress onto the mapped-input receiver or another proxy node, which hides the actual executing node and breaks lane cleanup when the mapped worker finishes.
• Queue-time rewrite has enough graph structure to estimate remote concurrency before execution starts. A stage decomposition of the remote component DAG is cheap to compute during prompt rewrite and useful to carry in extra_data.modal.
• Queue-time planning is still too early to launch Modal warmup containers because the prompt may only be waiting in ComfyUI's queue behind another remote workflow. Store the staged component plan, but tie actual warmup top-ups to runtime signals such as exact mapped fan-out once the proxy execution path is active.
• In-node progress bars are easy to lose underneath ComfyUI widgets. Rendering the remote progress UI in a small temporary panel below the node keeps sampler progress, parallel lanes, and batch badges readable without competing with text boxes or other widget chrome.
• Remote subgraph execution has to apply ComfyUI's primitive widget coercion before it calls PromptExecutor or manual local node execution. ComfyUI's validator converts literal INT, FLOAT, BOOLEAN, and STRING inputs in-place, and skipping that step remotely leaves values like steps=18.0 alive long enough to crash custom nodes that assume true Python integers.
• ComfyUI's CacheKeySetInputSignature is reusable for a distributed node-output cache, but the raw key object is an in-memory frozenset/tuple structure rather than a persistence-ready string. The workable approach is to canonicalize that structure into stable JSON, hash it into an NC_... key for Modal Dict, and only persist entries whose outputs are both transport-safe and below a strict size ceiling.
• Remote boundary injection can splice literal tensors back into CacheKeySetInputSignature objects for otherwise cacheable nodes like KSampler. Those tensors should contribute a stable content digest to the distributed cache key instead of poisoning the whole signature with ComfyUI's in-memory Unhashable marker.
• For remote distributed caching, cache_key_set.get_data_key(node_id) is not always reusable as-is. CacheKeySetInputSignature may already have converted boundary tensors into Unhashable, so the remote cache layer has to rebuild the same ancestry-based input signature from dynprompt and is_changed_cache before canonicalizing it for persistence.
• Restoring persisted outputs before PromptExecutor.execute() is too early. execute() immediately rebuilds the live cache-key set with its own set_prompt() call, so a distributed cache restore must run inside or immediately after that phase if the restored entries are supposed to participate in the actual execution walk.
• Mapped progress lanes have to preserve the scheduler-assigned lane id all the way through the remote worker. If the worker hardcodes every item's node progress to lane 0, concurrent mapped items overwrite each other in the frontend and upstream sampler bars appear to flicker or disappear entirely.
• Static mapped sub-runs cannot reuse the same "suppress status chatter" rule as per-item mapped lanes for numeric node progress. Those static phases usually do not have a lane id at all, so the local relay has to keep lane-less node_progress events for execute/boundary nodes or upstream samplers like KSampler will run remotely without ever showing a bar in the UI.
• Once those lane-less static progress events are forwarded, they also need their own explicit clear path. Suppressed static streams do not forward the terminal execution_success status event into the frontend, so relying on phase completion to clear ordinary progress leaves the last 100% sampler bar stuck onscreen.
• Distributed node-cache restore and persist should not be treated as unrelated phases. If one prompt run restores NC_<hash> into the live PromptExecutor cache and then persists the same node/key again unconditionally, Modal Dict churns on pure cache hits for no benefit; the persist pass should recognize restored hits and skip rewriting the same key.
• A distributed node-cache size cap that is generous enough for medium images can still be too expensive in practice. In these logs, repeatedly serializing and writing ~25 MiB cache entries dominated the post-execution phase, so the default cap should bias toward smaller transport-safe artifacts unless there is a clear reason to keep large intermediates.
• Once the persist phase knows a node is a restored-hit, that check has to happen before entry serialization and size estimation. Otherwise the code still burns CPU serializing outputs it already knows it is going to skip writing.
• Distributed node-cache restore also benefits from fan-out/fan-in structure. The old per-node await key -> await Dict get -> deserialize loop made total restore time roughly the sum of all independent Dict reads, while batching those lookups concurrently preserves prompt-order hydration but trims the network-bound portion substantially.
• Distributed node-cache restore must be boundary-aware. A downstream cache hit can make ComfyUI skip upstream dependency execution, so if that upstream node is also a boundary or session-bridge output, restoring only the downstream hit leaves no local cache entry to collect. Skip those downstream hits unless the required boundary ancestors are already local or restored too.
• Remote headless PromptServer shims need to track ComfyUI's UI-side helper surface, not only send_sync. Core API nodes like GetImageSize call PromptServer.instance.send_progress_text() during execution, and a missing no-op method is enough to fail otherwise valid headless remote runs.
• Implicit mapped fan-out cannot treat every Python list as a batch axis. ComfyUI semantic payloads like CONDITIONING are also list-backed, and splitting them per item corrupts the conditioning structure into fragments like ["cond", {...}] -> "cond" that later explode in sampler_helpers.convert_cond. Only explicitly batchable transport types and list-wrapped primitive sockets should participate in that automatic zipping path.
• Primitive widget sockets are not always scalar once a graph is running. Custom nodes can legally emit list(INT) or similar values into an INT input and rely on ComfyUI's normal over-list execution behavior, so remote validation should only reject list values that are still raw widget literals, not boundary-fed or upstream-fed runtime values.
• Singleton-list cleanup on the remote boundary needs the same nuance. It is correct to unwrap transport-added wrappers like [4] -> 4 and [[["node", [0]]]] -> ["node", 0], but wrong to flatten single-entry semantic payloads like [[tensor, meta]] for CONDITIONING; that shape change is enough to turn convert_cond() into a tensor indexing crash.
• Outer implicit batching cannot blindly fan out just because a boundary input is a list. If that split boundary lands on a node with INPUT_IS_LIST=True, the node needs the whole list in one call and ComfyUI should own any downstream over-list execution inside one PromptExecutor run; replaying the whole remote component per item duplicates scalar sibling work and turns single outputs into repeated lists.
• Local ComfyUI caching for remote proxies is extremely sensitive to transient payload fields. It was not enough to strip only prompt_id: cache-safe proxy payloads also had to drop run-scoped extra_data, volume-reload bookkeeping, and prompt-scoped session fields from original_node_data. Session-backed split proxies became cache-safe only after their exported bridge outputs switched from raw prompt-scoped session refs to durable replay refs backed by replay metadata in Modal Dict.
• Distributed cache keys for later split phases cannot rely on the prepared prompt alone. Once a non-transportable boundary input has been injected, the live prompt only contains a Python runtime object like ModelPatcher, and rebuilding CacheKeySetInputSignature from that prompt reintroduces the same unhashable-object problem. The fix is to carry a stable provenance fingerprint for each non-transportable boundary input, derived from the original upstream prompt subgraph, and hash that provenance instead of the live object identity.
• Live combined logs confirmed the current split-proxy weak point: worker affinity is best-effort, not a hard lease. One prompt-scoped session can be created on container A and a later phase can still land on container B, producing a RemoteSessionStateError even though neither worker is corrupted. That class of failure should not trigger container teardown; it needs stronger routing semantics.
• ModalMapInput cannot be treated as a remote-only marker. If the marker stays local and only the downstream sampler is remote-marked, rewrite still has to recognize that boundary as mapped work. Otherwise the remote component falls back to an ordinary subgraph, the boundary io_type degrades to *, and batched primitive lists like list(INT) seeds stop itemizing before they hit the sampler.
• A wildcard mapped boundary can still carry recoverable type information at runtime. If the value is a list of LATENT-like mappings or every target socket declares the same concrete input type, implicit batching should use that effective type instead of treating io_type="*" as an unconditional broadcast and handing a raw Python list to nodes like KSampler.latent_image.
• Modal background pollers can outlive the request-scoped gRPC client by a few milliseconds during asyncio.run() teardown. Threads that keep calling Modal SDK objects like Dict.contains() in that window must treat modal.exception.ClientClosed as a normal shutdown signal, otherwise successful runs end with noisy unhandled thread exceptions after the real work is already done.
• Split mapped proxies need their own seedable copy of the static producer phase. If the mapped proxy only carries remote-session bridge refs, fresh mapped workers have no way to populate those refs except replaying the durable bridge record payload item-by-item. Carrying a bridge-only static_phase on the mapped proxy lets the local scheduler prime each mapped lane once on its bound worker before sending any per-item sampler calls there.
• Seeded mapped lanes must not inherit clear_remote_session=True. If the seed payload clears the prompt-scoped session as soon as it finishes, the first mapped item on that lane throws away the whole point of seeding and has to fall back to warm-bridge restore immediately. Session teardown belongs only in the explicit final cleanup payload for that lane.
• Durable bridge replay metadata should carry directly restorable payloads for the remote-only types that can be serialized safely. CONDITIONING is the first useful case: its nested tensors fit the container RAM budget, so fresh workers can deserialize the conditioning straight back into the current remote session and skip producer replay for that bridge ref entirely.
• Nontransportable mapped state needs a different batching rule from raw semantic payloads. A plain CONDITIONING Python list usually encodes one conditioning structure and must stay broadcast, but a Python list whose elements are all remote session refs encodes per-item mapped remote values. Those ref lists need to split item-by-item even when the declared io_type is MODEL or CONDITIONING.
• Implicit mapped fan-out also needs its own session-lifetime rule. If every synthesized ::item:* or ::static payload inherits clear_remote_session=True, the first sibling to finish can tear down shared remote state while later siblings are still queued. Cleanup has to move into one explicit final payload that runs after all mapped siblings complete.
• Frontend mapped-progress lanes cannot be keyed only by laneId at prompt scope. Different remote components legitimately reuse local worker lane numbers like 0 and 1, so the UI has to namespace lane ownership by component representative or concurrent components will clear each other's purple bars and appear to flicker between active and ready states.
• Streamed remote progress should suppress native proxy executing churn, but not the proxy's terminal completion. If the frontend drops every native phase update after streamed progress starts, a single-node remote component can stay stuck purple because it only ever receives streamed finalizing and never consumes the completion event that should turn it green.
• The in-process "already auto-deployed" cache cannot be treated as authoritative once operators can delete the Modal app out-of-band. A later app not found lookup has to invalidate that cache entry and redeploy instead of assuming the earlier successful deploy still exists remotely.
• With deployed modal.Cls handles, "app missing" is not only a lookup-time failure. A stale handle can also survive lookup and then fail later during hydrate() or the first remote() call. The invoke path has to treat that the same way as a missing-app lookup, auto-deploy, and retry before surfacing an error locally.
• Mapped lane observability needs a distinct setup state, not just "first real progress wins." If the backend emits a dedicated setup_only lane progress event as soon as a worker starts seeding, the frontend can render a translucent pulsing placeholder bar while the lane is provisioning and then seamlessly replace it with real node progress once execution begins.
• Remote node UI needs two separate non-executing signals to stay legible under Modal fan-out: "ready but not in the active component" and "reused from the persisted node cache." The former should be derived locally from component membership and active_node_id, while the latter needs an explicit backend event because cached nodes often never emit ordinary execution progress at all.
• Once mapped fan-out is allowed to return before every spare lane finishes seeding, late failures from those detached lanes must not flow back through the main prompt future. They are no longer part of the critical path, so the scheduler has to ignore them after all outputs are already complete.
• Combined first-run and second-run performance logs are now clear enough to prioritize work. In this workflow, uploads and volume reload were already cheap, while the recurring non-sampling bottleneck was static-phase model loading (UNETLoader + CLIPLoader at roughly 24-25s total per run). The second run also showed that local proxy caching can skip the static proxy dispatch while still leaving a large replay cost inside the mapped phase, which makes two no-brainer optimizations obvious: reuse heavy loader outputs on the same worker, and avoid replaying the whole static producer branch just to reconstruct session-backed bridge values.
• Modal deployment updates are too permissive for GPU-type changes. Because a named deployed app can be updated in place while its resource expectations and synced storage assumptions may have come from an older COMFY_MODAL_GPU, the cloud entrypoint should fail local app construction when that app name already exists and require the operator to stop/delete the old app before building the new one.
• ComfyUI's cache setup indexes NODE_CLASS_MAPPINGS[class_type] before node execution starts, so missing custom-node registrations can surface as a raw KeyError from get_immediate_node_signature. Remote workers should preflight prompt class types after bundle extraction, retry external custom-node import once, and raise an explicit missing-class error if the registry is still incomplete.
• A successful custom-node sync only proves the package files reached Modal storage; it does not prove ComfyUI imported the package. When a synced class remains unregistered, the remote error should include whether the extracted bundle contains Python files mentioning that class and which top-level package they came from, so the next debugging step is import failure logs instead of another sync toggle check.
• Stale deployed Modal apps are not limited to missing-app failures. The local client needs an explicit app protocol handshake with RemoteEngine, and an unversioned or older remote app should be stopped and replaced before payload execution so local code changes are not silently tested against an old image.
• Remote execution and asset sync must derive their mode from the same settings snapshot. If sync uses LocalMirrorVolume but invocation reads a newer raw COMFY_MODAL_EXECUTION_MODE=remote value, the logs misleadingly show custom-node sync success while the Modal worker cannot see the bundle; queue rewrite should fail before dispatch in that split-brain state.
• Modal volume duplicate-file errors are benign for content-addressed upload paths. If /custom_nodes/entries/.../<sha>_custom_nodes_bundle.zip already exists, the digest in the path is the identity check, so the sync engine should mark the upload as present instead of failing the run.
• ComfyUI's execution-error current_inputs display stringifies complex values like CONDITIONING, so a quoted tensor dump in the error payload is not proof that transport serialization converted the conditioning to text. If the real failure is a missing sampler input, preflight required node inputs before PromptExecutor so the error points at the malformed prompt shape directly.
• Modal proxy execution needs prompt-level admission control, not just per-call awaiting. ComfyUI can have multiple async proxy executions in flight, so a second prompt can otherwise dispatch Modal work while the first prompt's remote components are still running. Gating by prompt_id preserves within-prompt component parallelism while making later prompts wait for the active prompt's remote calls to drain.
• Prompt cancellation creates two separate state problems. The local proxy gate must be cancellable while it is waiting behind another prompt, otherwise a cancelled waiter can later acquire the gate and confuse subsequent prompts. The frontend also needs a terminal prompt marker so late Modal status/progress events from a cancelled remote worker are ignored instead of recreating the global status pill after cleanup.
• Queue-time Modal UI updates are not execution-start signals. When a user submits a new Modal prompt while an older Modal prompt is still active, the frontend must register the new prompt metadata but suppress setup/ready node coloring until a real ComfyUI execution or Modal progress event arrives for that prompt. Otherwise a queued prompt visually appears to have started before ComfyUI has actually advanced past the current remote workflow.
• Node progress needs a short completion lifecycle. Clearing progress immediately on executed makes completion visually abrupt, but leaving the progress payload around keeps the node looking active. Marking progress as fading lets the node switch to complete styling while the bar fades out and is removed after a bounded delay.
• Local proxy execution is not proof that a Modal worker is running the graph. The frontend should keep the global pill in an orange waiting state while ComfyUI is executing the proxy and Modal is still provisioning capacity, and only switch to green running once streamed remote feedback includes an active remote node or actual node-progress data.
• A Modal cancellation flag can be written before the remote method body starts if the user cancels while Modal is still provisioning capacity. Remote execution registration must not clear that key on entry, and the local proxy still needs a bounded post-interrupt grace period so ComfyUI is released even when remote code is slow to observe the interrupt.
• ComfyUI's interrupt flag is cooperative, so some remote workflows keep running after the shared Modal cancellation flag is consumed. The remote interrupt monitor should schedule a short, cancellable worker-process exit when it observes cancellation, and cancel that exit only if the prompt unwinds before the timeout.
• A split mapped proxy can carry an embedded static_phase that is executed later for mapped lane seeding. Any original boundary inputs required by that embedded phase must still be wired onto the mapped proxy node, even if they are not part of the mapped payload's top-level boundary_inputs; otherwise the remote worker reaches lane seeding with no hydrated value for names like remote_input_0.
• Remote execution streams do not reliably produce explicit completion events for every node, especially quick nodes or nodes without numeric progress. The local stream bridge still has the remote subgraph prompt, so it should send dependency ancestors for each active/progress node and let the frontend mark those ancestors complete before painting the current node active.
• Coarse component-level execution status is allowed to say "these nodes are ready", but it must not downgrade same-prompt nodes that were already marked complete. Some prompt input structures also wrap links inside nested lists or dicts, so graph ancestry helpers need recursive link discovery instead of checking only top-level [node_id, output_index] values.
• Syncing a custom-node package's Python files is not enough for remote execution. If the package carries a requirements.txt, those requirements have to be part of the Modal image build, because subprocess-heavy nodes like PiD import their vendored code inside the remote container and fail late with ordinary ModuleNotFoundError errors such as missing omegaconf.
• The remote planner should never execute a workflow node merely because it is downstream of a marked remote node. Unmarked preview/UI branches are not enumerable across custom nodes, so they must stay in the local prompt and consume proxy boundary outputs instead of being absorbed into remote component_node_ids or execute_node_ids.
• Component membership is useful as visible debugging state, not only hidden scheduler metadata. Prompt-local component labels can be derived from the backend component list and drawn on each Modal node, which lets users see which remote nodes are assigned together without exposing long representative node ids.
• Worker affinity cannot be the only protection for sampler-produced bridge values. If a downstream phase lands on a fresh worker, serialized LATENT bridge records let the worker restore sampler output directly while still preserving the invariant that sampler producer components are never replayed as a fallback.
• A MODEL bridge can be produced inside a sampler component without being sampler output itself, for example UNETLoader -> LoraLoaderModelOnly -> KSampler. Durable rehydration should trim to the requested model output's dependency closure and reject the plan only if that closure contains sampler work, instead of treating the whole producer component as replay-only.
• CLIP bridges have the same failure mode as linked MODEL bridges when a sampler component exports shared text-encoder state. Durable bridge rehydration should cover loader-style remote-only outputs such as MODEL, CLIP, and VAE, not only model patchers.
• Durable subgraph rehydration plans can themselves depend on earlier bridge refs. They must execute inside the downstream target remote_session, otherwise nested bridge resolution has no session to restore into and fails before it can rebuild the requested loader-style output.
• Dispatch-time feedback is separate from real remote execution. When Modal is provisioning or all warm workers are occupied, the local proxy can wait tens of seconds before the first streamed active-node event arrives, so the local dispatch path should emit a lightweight starting status immediately and let later streamed progress replace that temporary orange state.
• Prompt-wide active-node state is not a safe completion signal under parallel remote execution. If two components stream sampler progress at the same time, alternating events must not fade or complete the previous active node unless both nodes belong to the same remote component.
• Modal UI preflight and dispatch waiting need separate states. Orange setup should mean graph/package/upload work, while yellow starting should mean a component has been locally dispatched and is waiting for Modal to stream real node execution. The global pill should also ignore stale active-node ids unless that node still has active state or live progress.
• ComfyUI targeted interrupts only call nodes.interrupt_processing() when the prompt id still appears in the native running queue. Modal proxy calls can be blocked on remote work after that native check stops seeing the prompt, so active Modal prompt ids need to be exposed back through the local prompt queue for /interrupt {"prompt_id": ...} to propagate cancellation instead of logging "not currently running".
• Cancellation can also arrive before a Modal payload reaches the registered remote-call wrapper, especially during first-run auto-deploy or deployed-app readiness polling. The outer local waiter must write the shared cancel flag and enforce the same local release grace during deploy/provisioning, and the worker must refuse to start the remote payload if cancellation was already observed.
• Users need immediate cancellation feedback even when Modal cleanup is still cooperative. The frontend should intercept ComfyUI /interrupt requests, mark the prompt as cancelling, and ignore nonterminal late progress until the native terminal event clears the UI.
• Prompt-level Modal cancellation has to release both the remote work and the local prompt admission gate. If a user cancels during Modal deploy/readiness, ComfyUI can mark the prompt interrupted while the background Modal call still owns the local gate, leaving the next prompt stuck behind an already-cancelled prompt id.
• ModalMapInput does not remove the need for ordered split proxies. If a mapped remote component has a local re-entry dependency, such as an early sampler preview feeding a local text/image node that returns into a later mapped sampler, the static side must still split into ordered phases before the mapped phase or the rewritten prompt can create a false dependency cycle.
• Implicit mapped cancellation has to stop the local item scheduler, not only the remote payload that is currently running. If a sampler lane observes a prompt interrupt, queued sibling items and final cleanup payloads must be suppressed immediately or a quick cancel/restart can dispatch stale mapped sampler work after the UI already reports cancellation.
• ModalMapInput should accept scalar primitive values as a one-item map. This keeps the marker useful as a no-op adapter when an upstream control value like INT is not batched, while preserving fan-out behavior for lists, tensor batches, and LATENT mappings.