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.

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 <- err

View on GitHub (pinned to 329838acdf)

Solutions

1. Search the daemon log for `recovered from panic exporting` to find the CID, panic value, and stack trace.
2. Verify the block data with `ipfs dag stat` / `ipfs block get` on the affected CID to identify the corrupt block.
3. Report the stack trace to kubo/boxo (github.com/ipfs/kubo/issues) since a panic in a codec is a bug.
4. Work around locally by removing/re-fetching the corrupt block (gc + re-download) if the source was bad.

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
}

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

• internal error encoding node
• got unexpected output from util.RmBlocks
• panic(err)
• BUG: unhandled autonat service mode

AI-assisted analysis of ipfs/kubo@329838acdf (2026-09-03). Data as JSON: /api/errors/e28bafbd59840223. Report an issue: GitHub.