The diagnosis panel offered a "Kill vLLM processes" (pkill -f vllm) recovery
for ANY Python traceback — including pip build failures and other tracebacks
that have nothing to do with vLLM. That advice is useless for a build failure
and harmful if an unrelated vLLM server happens to be running.
ERROR_PATTERNS in static/js/cookbook-diagnosis.js had one catch-all traceback
matcher that always attached the vLLM-kill fix. Split it into three (all
keeping the existing healthy-server suppression):
- pip build failure (Failed to build / metadata-generation-failed /
subprocess-exited-with-error / Could not build wheels) -> "a dependency
failed to build" message, no kill.
- vLLM-specific traceback (tail mentions vllm) -> keeps the kill, now scoped.
- any other traceback -> neutral "check the captured output" message, no kill.
How to test:
- node --check static/js/cookbook-diagnosis.js
- Trigger a wheel-build failure (old package on a newer Python) or a non-vLLM
traceback and open the diagnosis. Before: generic traceback message + "Kill
vLLM processes" button. After: a build-failure / neutral message with no kill;
only a real vLLM traceback still offers it.
Fixes#4516
Co-authored-by: Claude
_showDiagnosis referenced an undefined `body` (left over from the refactor
that moved the diagnosis text into the toolbar), throwing a ReferenceError
whenever a failed task rendered fix buttons. Because open() wraps its render
in try/finally with no catch, the throw escaped before the modal was
un-hidden, so the whole Cookbook silently failed to open.
- cookbook-diagnosis.js: append the fixes row to `diag` (the in-scope
container) instead of the removed `body` element.
- cookbook.js: guard the render passes in open() so one broken task card
can't leave the entire panel stuck hidden.
Fixes#4406
