ipfs/kubo · critical
internal error during CAR export
Error message
internal error during CAR export
What it means
The CAR export traversal runs third-party codec decoding code, and a panic there would kill the whole daemon, so the goroutine registers a `recover()` handler. When a panic is caught, the original panic (with stack) is logged server-side and this generic sentinel error is sent to the caller instead. It intentionally hides internal details from the user while preserving the crash trace in the daemon log.
Solutions
- Search the daemon log for `recovered from panic exporting` to find the CID, panic value, and stack trace.
- Verify the block data with `ipfs dag stat` / `ipfs block get` on the affected CID to identify the corrupt block.
- Report the stack trace to kubo/boxo (github.com/ipfs/kubo/issues) since a panic in a codec is a bug.
- Work around locally by removing/re-fetching the corrupt block (gc + re-download) if the source was bad.
Defensive patterns
Strategy: fallback
Try / catch
if strings.Contains(err.Error(), "internal error during CAR export") {
// inspect daemon log for "recovered from panic exporting" and the CID
// retry with a different node or after removing/re-fetching the corrupt block
} Prevention
- Keep kubo and boxo updated to pick up codec panic fixes.
- Validate DAG integrity (ipfs dag stat) before exporting untrusted content.
- Monitor daemon logs for recovered panics to catch corrupt blocks early.
When it happens
Trigger: The block traversal/codec code for the requested CID panics: typically malformed or corrupt block data whose decoder hits an unhandled edge case, or a bug in an IPLD codec invoked during `exportPartialCAR` or the full CAR export path.
Common situations: Exporting a DAG containing corrupt or adversarially crafted blocks; a codec implementation bug for an exotic IPLD codec; memory corruption triggered during traversal of a huge DAG.
Related errors
- BUG: unhandled autonat service mode
- got unexpected output from util.RmBlocks
- internal error encoding node
- panic(err)
AI-assisted analysis of ipfs/kubo@329838acdf (2026-09-03).
Data as JSON: /api/errors/e28bafbd59840223.
Report an issue: GitHub.
Appendix: source
Thrown at core/commands/dag/export.go:100
errCh := make(chan error, 2) // we only report the 1st error
go func() {
defer func() {
if err := pipeW.Close(); err != nil {
errCh <- fmt.Errorf("stream flush failed: %s", err)
}
close(errCh)
}()
// Traversal decodes blocks with whatever codec their CID names, so it
// runs third-party code. This goroutine is detached from the request,
// and a panic on it would end the daemon rather than the command.
// Registered after the close above so it runs first, while errCh is
// still open.
defer func() {
if rec := recover(); rec != nil {
log.Errorf("recovered from panic exporting %s: %v\n%s", c, rec, debug.Stack())
errCh <- errors.New("internal error during CAR export")
}
}()
if localOnly {
if err := exportPartialCAR(req.Context, bs, c, pipeW); err != nil {
errCh <- err
}
return
}
lsys := cidlink.DefaultLinkSystem()
lsys.SetReadStorage(&dagStore{dag: api.Dag(), ctx: req.Context})
// Uncomment the following to support CARv2 output.
/*
car, err := gocar.NewSelectiveWriter(req.Context, &lsys, c, selectorparse.CommonSelector_ExploreAllRecursively, gocar.AllowDuplicatePuts(false))
if err != nil {
errCh <- errView on GitHub (pinned to 329838acdf)