What causes "no span %q in this trace" in dagger/dagger?

Confirm you loaded the trace file that actually contains this span ID

no span %q in this trace

Error message

no span %q in this trace

What it means

resolveTraceTargetIn parsed the target's span ID but no span with that hex ID exists in the loaded trace's dagui DB. The user-supplied span selector points outside the trace being read (wrong trace, stale span ID, or the span was never recorded).

Source

Thrown at core/trace_target.go:105

//     started matching span.
//
// Most-recent-wins because a name is how a reader refers to a check or test
// they just saw run: when a name matched several spans (a retried check, a
// test case run under more than one suite), the latest one is the one they
// mean.
func resolveTraceTargetIn(db *dagui.DB, target traceTarget) (string, error) {
	switch {
	case target.empty():
		return "", fmt.Errorf("ReadTrace needs a target: pass span (a hex span ID), " +
			"check (a check name, e.g. \"lint:check\"), or test (a test case or suite name)")

	case target.Span != "":
		id, err := trace.SpanIDFromHex(target.Span)
		if err != nil {
			return "", fmt.Errorf("invalid span ID %q: %w", target.Span, err)
		}
		if _, ok := db.Spans.Map[dagui.SpanID{SpanID: id}]; !ok {
			return "", fmt.Errorf("no span %q in this trace", target.Span)
		}
		return target.Span, nil

	case target.Check != "":
		// Resolve by scanning span check names directly, NOT via
		// DB.SurfacedChecks: surfacing answers "should this check be listed in
		// a report", which depends on Boundary/Encapsulate containment -- and a
		// check run inside an LLM tool call always has a Boundary ancestor (the
		// tool-call display span). A name lookup must not inherit that: the
		// reader is naming something it just saw run.
		names := map[string]bool{}
		var best *dagui.Span
		for span := range db.Spans.Iter() {
			if span.CheckName == "" {
				continue
			}
			names[span.CheckName] = true
			if span.CheckName != target.Check {

View on GitHub (pinned to 82ba2681db)

Solutions

Confirm you loaded the trace file that actually contains this span ID
Use the check or test name form to resolve by name within the current trace
List available spans from the report session and pick one present in it

Example fix

// before
id, err := resolveTraceTarget(db, traceTarget{Span: oldSpanID})
// after
if _, ok := db.Spans.Map[dagui.SpanID{SpanID: sid}]; !ok {
	return fmt.Errorf("span %s not found; did you load the right trace?", sid)
}
id, err := resolveTraceTarget(db, traceTarget{Span: oldSpanID})

Defensive patterns

Strategy: validation

Validate before calling

sid, _ := trace.SpanIDFromHex(spanArg)
if _, ok := db.Spans.Map[dagui.SpanID{SpanID: sid}]; !ok {
	return fmt.Errorf("span %s not in loaded trace", spanArg)
}

Try / catch

id, err := resolveTraceTarget(db, target)
if err != nil && strings.Contains(err.Error(), "no span") {
	// list spans from db.Spans.Map and prompt for a valid one
}

Prevention

Confirm the loaded trace file matches the run the span came from
List available span IDs from the session before targeting one
Avoid caching span IDs across different trace loads

When it happens

Trigger: Calling resolveTraceTarget with a syntactically valid span ID that belongs to a different trace or was captured in another session.

Common situations: Pointing ReadTrace at trace A while copying a span ID from trace B; an old span ID from a previous engine run that is not in the current trace file.

Related errors

AI-assisted analysis of dagger/dagger@82ba2681db (2026-09-05). Data as JSON: /api/errors/e0297c342f25176c. Report an issue: GitHub.