Skip to content

fix: finalize async-tar Builder on upload error to avoid worker-thread panic - #786

Merged
norrietaylor merged 1 commit into
mainfrom
inbox-patch/async-tar-builder-finalize-934289ae54bd1a94
Jul 16, 2026
Merged

fix: finalize async-tar Builder on upload error to avoid worker-thread panic#786
norrietaylor merged 1 commit into
mainfrom
inbox-patch/async-tar-builder-finalize-934289ae54bd1a94

Conversation

@gominimal-aw-bot

Copy link
Copy Markdown
Contributor

Fixes #783
Routing-Key: inbox-route/I_kwDOSUhdos8AAAABI_XyLQ

Problem

min activate streams the project directory to the daemon as a tar+zstd archive built on a background task (crates/minimal/src/file_upload.rs). The tar Builder was finalized with into_inner() only on the success path.

When the upload channel closes mid-stream, the tokio::io::copy in stream_tar_zstd returns an error and the function returns early, dropping the duplex reader. The background build task's next write to the pipe then fails, so add_dir_entries returns early via ? — dropping the Builder without finalizing it. async-tar 0.6.1's Builder::drop panics in that case (Builder dropped without finalizing; call finish() or into_inner(), builder.rs:671), crashing a tokio worker thread on top of the real error the user already saw.

Fix

Extract the archive construction into build_tar_zstd, which always calls into_inner() to finalize the Builder — even when adding entries failed — before propagating the original error. Because the builder is finalized on every path, its Drop guard never fires, so a mid-stream channel close now surfaces as only the clean Failed to upload project files: ... channel closed error with no panic.

The change is confined to the sender-side upload path; no receiver-side change was needed. Feature area confirmed against the tarball session-population work in this repo (informed by #423).

A regression test (file_upload::tests::build_surfaces_error_when_writer_fails_mid_stream) drives build_tar_zstd with a writer that fails part-way through the (incompressible) stream and asserts the failure surfaces as an Err rather than a panic.

Verification

  • cargo fmt --all --check --manifest-path target/Cargo.toml — clean, no drift.
  • cargo clippy --workspace --manifest-path target/Cargo.toml -- -D warnings — finished, no warnings.
  • cargo build --workspace --manifest-path target/Cargo.tomlFinished in 1m 19s, no errors.
  • cargo test --workspace --manifest-path target/Cargo.toml — passed (exit 0); the minimal lib reports test result: ok. 6 passed; 0 failed including the new regression test.

Generated by inbox-patch ·

@coderabbitai

coderabbitai Bot commented Jul 16, 2026

Copy link
Copy Markdown

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 14 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ed101bae-d16f-4068-bf7a-4d7a00f2da8e

📥 Commits

Reviewing files that changed from the base of the PR and between 5ca67a5 and 5ad0cc0.

📒 Files selected for processing (1)
  • crates/minimal/src/file_upload.rs

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

The `min activate` upload path dropped the async-tar `Builder` without
calling `finish()`/`into_inner()` when the upload channel closed
mid-stream, tripping the `Builder`'s `Drop` panic on a tokio worker
thread. Always finalize the builder before propagating the error so the
failure surfaces cleanly.

Fixes #783
@norrietaylor
norrietaylor force-pushed the inbox-patch/async-tar-builder-finalize-934289ae54bd1a94 branch from b6c255f to 5ad0cc0 Compare July 16, 2026 04:35
@norrietaylor
norrietaylor marked this pull request as ready for review July 16, 2026 05:17
@norrietaylor
norrietaylor merged commit 80fa818 into main Jul 16, 2026
28 checks passed
@norrietaylor
norrietaylor deleted the inbox-patch/async-tar-builder-finalize-934289ae54bd1a94 branch July 16, 2026 18:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Tarball processing panic: "Builder dropped without finalizing"

2 participants