swc-project/swc · error
failed to handle with unknown panic message
Error message
failed to handle with unknown panic message
What it means
The fallback arm of the HTML binding's panic bridge: the panic payload inside the @swc/html native operation was neither String nor &str, so no readable text could be extracted and the error surfaces as 'failed to handle with unknown panic message'. It still means a Rust panic occurred and was contained before crashing Node, but the payload type carried no message.
Solutions
- Rerun with RUST_BACKTRACE=1 to capture where the panic originated before the bridge converts it
- Minimize the HTML input (bisect the document) to isolate the trigger and report upstream with the repro
- Disable suspicious minify options one by one to find the pass that panics
- Verify the panic is not caused by a custom panic::set_hook in the embedding process
Example fix
// before
const r = minify(html, opts); // 'unknown panic message'
// after: diagnose with backtraces enabled
// RUST_BACKTRACE=1 node build.js
try {
const r = minify(html, opts);
} catch (e) {
// e.message === 'failed to handle with unknown panic message'
bisectAndReport(html, opts);
} Defensive patterns
Strategy: try-catch
Try / catch
try {
const out = minify(html, opts);
} catch (e) {
if (e.message === 'failed to handle with unknown panic message') {
// degrade gracefully: emit unminified HTML and log for later diagnosis
return html;
}
throw e;
} Prevention
- Keep a fallback path (skip minification) for the affected document so one bad page cannot block deploys
- Reproduce opaque panics with RUST_BACKTRACE=1 to capture origin
- Bisect the document to a minimal failing fragment before reporting upstream
When it happens
Trigger: A panic with a structured/unit payload (panic!(()), non-string types, custom panic hooks) inside the HTML transform invoked from @swc/html.
Common situations: Memory/allocator-level aborts, poisoned locks, or native plugins with non-string panics; debugging is harder because the message carries no root cause, so environment-level tracing is required.
Related errors
- failed to handle
- failed to handle with unknown panic message
- failed to handle
- assignment property be removed before generator pass
- attr_to_prop(JSXEmptyExpr)
AI-assisted analysis of swc-project/swc@5176682b65 (2026-08-17).
Data as JSON: /api/errors/69f6614d9c8a0017.
Report an issue: GitHub.
Appendix: source
Thrown at bindings/binding_html_node/src/util.rs:31
skip_filename: false,
..Default::default()
},
|handler| {
//
let result =
std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| op(&cm, handler)));
let p = match result {
Ok(v) => return v,
Err(v) => v,
};
if let Some(s) = p.downcast_ref::<String>() {
Err(anyhow!("failed to handle: {s}"))
} else if let Some(s) = p.downcast_ref::<&str>() {
Err(anyhow!("failed to handle: {s}"))
} else {
Err(anyhow!("failed to handle with unknown panic message"))
}
},
)
.map_err(|e| e.to_pretty_error())
}
View on GitHub (pinned to 5176682b65)