fix: finalize async-tar Builder on upload error to avoid worker-thread panic - #786
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 14 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
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
b6c255f to
5ad0cc0
Compare
Fixes #783
Routing-Key: inbox-route/I_kwDOSUhdos8AAAABI_XyLQ
Problem
min activatestreams the project directory to the daemon as a tar+zstd archive built on a background task (crates/minimal/src/file_upload.rs). The tarBuilderwas finalized withinto_inner()only on the success path.When the upload channel closes mid-stream, the
tokio::io::copyinstream_tar_zstdreturns an error and the function returns early, dropping the duplex reader. The background build task's next write to the pipe then fails, soadd_dir_entriesreturns early via?— dropping theBuilderwithout finalizing it.async-tar0.6.1'sBuilder::droppanics 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 callsinto_inner()to finalize theBuilder— even when adding entries failed — before propagating the original error. Because the builder is finalized on every path, itsDropguard never fires, so a mid-stream channel close now surfaces as only the cleanFailed to upload project files: ... channel closederror 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) drivesbuild_tar_zstdwith a writer that fails part-way through the (incompressible) stream and asserts the failure surfaces as anErrrather 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.toml—Finishedin 1m 19s, no errors.cargo test --workspace --manifest-path target/Cargo.toml— passed (exit 0); theminimallib reportstest result: ok. 6 passed; 0 failedincluding the new regression test.