Diagnosing ComfyUI Task Failures

When facing a wall of failed tasks like the one above, don't inspect them one-by-one. Instead:

1. Group failures by node/model type (e.g., "Flux2-Klein-9B双图编辑" vs "Minimax参考生视频V1")
2. Check if failures are 100% for one model type — that points to a config/credential/version issue, not random flakiness
3. Check run duration before failure — short (~1 min) vs long (~4 min) failures indicate different failure stages (input validation vs. generation timeout)
4. Pull the taskid of the most recent failure and inspect its full error log first — recent failures are most relevant to current state

Progress:

• Step 1: Categorize all failed tasks by node type and run mode
• Step 2: Identify timing pattern (failures clustering at short duration = input/setup error; long duration = generation/API error)
• Step 3: Check for common root cause across a model type (all Minimax tasks failing but all Flux2-Klein succeeding suggests a Minimax-specific issue)
• Step 4: Inspect the preview/output node config — confirm output routing isn't silently failing (task succeeds but preview doesn't display)
• Step 5: Pull raw logs for 1-2 representative taskids per failure category
• Step 6: Check account/member status, API quotas, and credential expiry (common hidden cause)
• Step 7: Re-run one isolated test task per failing node type after fix
• Step 8: Confirm fix resolves failures before batch re-running queued tasks

Step-by-step diagnostic logic

1. Categorize by node type Separate failures into buckets:

• Flux2-Klein-9B双图编辑 (image editing, short duration ~50s-1min06s)
• Minimax参考生视频V1 (video generation, long duration ~3min39s-4min54s)

2. Look at duration signature

• Flux2-Klein failures: consistently under 1min10s → likely failing early (bad input pair, missing second image, malformed prompt, or node connection issue) rather than mid-generation
• Minimax failures: consistently 3.5-5 min → likely failing late in generation (API timeout, content policy rejection, or backend service instability) — NOT an input problem

3. Check for total failure vs partial failure If every single task of a given type failed (as shown: 100% failure rate across ~20 consecutive tasks for both node types), this is a systemic issue:

• Expired/exhausted account credits or member status (note: "会员还有0天就到期啦" — membership expiring in 0 days is a strong candidate root cause)
• Backend service outage for that specific model
• Broken workflow template (someone edited/corrupted the node graph)

4. Cross-reference with account status The membership expiry banner ("会员还有0天就到期啦，续费继续畅快体验") appearing alongside mass task failures is the top suspect — expiring/expired membership commonly throttles or blocks Standard-mode task execution.