fix(file): copy part bytes to avoid Bun FetchTasklet segfault#244
Conversation
Bun's FetchTasklet teardown (Blob.Any.detach) can segfault when fetch is given a BunFile-backed Blob slice during multipart upload, which was the root cause behind the `oo file upload` crash tracked in #242. Materializing the part into a fresh Uint8Array before handing it to fetch sidesteps the lazy file-backed code path entirely. With the underlying issue fixed in code, the CI workflows no longer need the `bun-version: canary` workaround, so they are switched back to the pinned `.bun-version` file. The publish cache key also picks up `.bun-version` so cache entries invalidate when the runtime version changes. Signed-off-by: Kevin Cui <bh@bugs.cc>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
Summary by CodeRabbitRelease Notes
WalkthroughThis PR makes two independent changes. First, it updates four GitHub Actions workflows ( Possibly related PRs
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches✨ Simplify code
Comment |
Bun's FetchTasklet teardown (Blob.Any.detach) can segfault when fetch
is given a BunFile-backed Blob slice during multipart upload, which
was the root cause behind the
oo file uploadcrash tracked in#242. Materializing the part into a fresh Uint8Array
before handing it to fetch sidesteps the lazy file-backed code path
entirely.
With the underlying issue fixed in code, the CI workflows no longer
need the
bun-version: canaryworkaround, so they are switched backto the pinned
.bun-versionfile. The publish cache key also picksup
.bun-versionso cache entries invalidate when the runtimeversion changes.