Shut the batch span processor down when the console one fails

[ayaangazali]

LogfireSpanProcessor is the span processor the Node SDK installs by default (sdk.ts:391). It wraps the BatchSpanProcessor that holds spans on their way to OTLP, and optionally a console processor. Both lifecycle methods awaited them in sequence:

async forceFlush(): Promise<void> {
  await this.console?.forceFlush()
  return this.wrapped.forceFlush()
}

async shutdown(): Promise<void> {
  await this.console?.shutdown()
  return this.wrapped.shutdown()
}

If the console call rejects, the second line never runs. this.wrapped is the batch processor, and its shutdown is what exports whatever is still queued, so the failure that skips it is exactly the moment those spans are lost.

Against main, with the console exporter's shutdown rejecting:

BatchSpanProcessor.prototype.shutdown calls: 0

This repo has settled the same shape twice. TailSamplingProcessor.runBoth says it directly:

Awaiting them in sequence would skip the second one whenever the first rejects, which is exactly when the deferred processor still needs the call.

And f9dedfa gave flushRuntime and shutdownRuntime a shared settle-and-report seam for the same reason. This processor was not covered by either.

The fix starts both calls, waits for both, rethrows a lone failure unchanged so the existing rejection contract is unaffected, and raises two as an AggregateError. Waiting concurrently also stops a slow console flush from eating into the deadline flushRuntime now applies.

Being straight about severity: I did not find an input that makes the console side reject on its own today. LogfireConsoleSpanExporter.shutdown resolves, and the global console swallows write errors, so this is currently a contract gap rather than a live data loss. It matters because the console exporter is the replaceable, I/O-doing half of the pair and the batch processor is the half whose loss is unrecoverable, and because the two precedents above already decided this ordering is wrong.

Built this with Claude Code's help and reviewed the diff myself.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 75fdd7b6-6192-4d4c-96f6-d1f516f0a8e6

📥 Commits

Reviewing files that changed from the base of the PR and between 6cc4212 and 1120b67.

📒 Files selected for processing (3)

• .changeset/node-processor-lifecycle.md
• packages/logfire-node/src/__test__/traceExporter.test.ts
• packages/logfire-node/src/traceExporter.ts

🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

• pydantic/logfire (manual)
• pydantic/pydantic-ai (manual)

Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review.

---

📝 Walkthrough

Walkthrough

settleBoth now waits for console and wrapped span processor lifecycle operations concurrently. forceFlush and shutdown use this helper. One rejection is rethrown unchanged. Two rejections produce an AggregateError. Tests cover cleanup after shutdown failure and simultaneous flush failures. A patch changeset documents the behavior.

Merge Risk: ⚪ Minimal · up to 1120b

Console processor failures no longer prevent the wrapped batch processor from flushing or shutting down, while lifecycle errors remain visible to callers. The change is ready to merge.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description clearly explains the lifecycle failure, the concurrent settlement fix, and the resulting error behavior. It directly matches the changeset and objectives.
Title check	✅ Passed	The title clearly identifies the main lifecycle fix: the batch span processor still shuts down when the console processor fails. It is concise and specific.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}