A ComfyUI troubleshooting handoff that another person can reproduce
A useful troubleshooting handoff lets another person reproduce the first failure without guessing your model, extensions or settings. Reduce the problem to a safe example and preserve the distinction between what you observed, what you changed and what you merely suspect.
Capture the first observable failure
Save the complete error report and identify the stage where execution stops. Record whether the application fails to start, a model cannot load or the graph fails later during processing. A vague statement that AI is slow or broken does not identify a testable problem.
Keep the original graph and environment record before changing anything. Include ComfyUI and extension revisions, model identifiers and relevant hardware information. Do not publish credentials, account details or private directory names in the material you share.
For the handoff, include an ordered action list and the expected output filename. Ask the receiving operator to report the first step that differs, rather than changing several settings before confirming whether the original failure can be reproduced.
Create a minimal safe example
Use a permitted input that exhibits the same failure without exposing client work. Start from a maintained basic workflow and add only the component needed to reproduce the problem. If the issue disappears, record that observation rather than assuming the original cause has been established.
Avoid changing the model, backend and extensions together during reduction. A useful comparison isolates one difference. Preserve the failing and passing graphs with clear labels so a reviewer can verify what actually changed between them.
Separate observation from explanation
Report the action performed, the expected result and the actual result. Put a proposed cause in a separate hypothesis field. An out-of-memory message, a missing file and an invalid connection are different observations and should not all be described as insufficient GPU power.
Include whether the failure repeats after restart and whether it depends on a particular input. Fixed seeds can help organize an image comparison, but environment differences can affect reproducibility. Keep saved outputs and logs rather than relying on a claim that the seed alone recreates the issue.
Verify the proposed correction
Apply a suggested change in a recoverable test copy and rerun the same example. Check the final saved output, not merely the absence of an error dialog. Then test the original workload to confirm that reducing the example did not remove an essential requirement.
Record the correction, versions and remaining limitations in the issue report. This US edition replaces unverified quotations and conceptual code with a practical collaboration process. It does not claim a new hardware benchmark or certify an unspecified extension; its outcome is a small, inspectable report that supports a real diagnosis.