9 days ago
Hi Railway team,
I'm hitting a persistent build failure on my service that's now blocking a live-user-facing deploy. The build fails during the toolchain-install step (mise install) with an HTTP/2 stream error while downloading the Bun binary — Node and Caddy always install successfully in the same build, only Bun's download fails.
Project/Service: robotech-ims-server (inventory-management-client), environment: staging
Error (consistent across attempts):
mise bun@1.3.14 [1/3] download bun-linux-x64.zip
mise ERROR Failed to install core:bun@1.3.14: error sending request: client error (SendRequest): http2 error: stream error received: refused stream before processing any application logic
What I've tried, in order, all failing identically:
Initial deploy — failed on bun@1.3.14 download.
Retried deploy — failed with a different symptom, exit code 137 (OOM/killed) on caddy install instead.
Retried again — back to the same bun@1.3.14 HTTP/2 stream refusal.
Set NO_CACHE=1 and redeployed to rule out a stale cache — still failed identically on bun@1.3.14.
Pinned Bun to 1.3.13 explicitly (via .bun-version, package.json packageManager and engines fields) and redeployed with NO_CACHE=1 still set — failed with the exact same HTTP/2 stream refusal, just on bun@1.3.13 instead.
Removed NO_CACHE=1 and redeployed an older commit — this one succeeded, likely because it hit a cached Bun binary from an earlier attempt rather than re-downloading.
Deployed my actual (newer) commit with caching left on — failed again, same error.
Notable pattern:
Every single failed build has been scheduled on the same builder: builder-oufpis.
Node's toolchain download never fails in any of these builds — only Bun's.
Two different Bun versions have failed with the identical HTTP/2 "refused stream" error, ruling out a bad release artifact for one specific version.
Caching on/off, and cache-cleared builds, all show the same behavior for fresh Bun downloads specifically.
Given the consistency on builder-oufpis and that only Bun's download path is affected while Node/Caddy work fine, this looks like it could be a networking issue specific to that builder's egress path to the Bun release CDN, rather than something on my end.
This is currently blocking a deploy for a live production feature. Could you please investigate builder-oufpis, or let me know if there's a way to request scheduling on a different builder? Happy to provide full build logs for any/all of the attempts above if useful.
Thanks,
5 Replies
9 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 9 days ago
medim
Out of curiosity, do you have a `packageManager` field on your package.json?
9 days ago
Yup
" "packageManager": "bun@1.3.13",
"engines": {
"bun": "1.3.13"}," here is its value
9 days ago
I have started using Dockerfile instead of Railpack all is good now/
mensurui
I have started using Dockerfile instead of Railpack all is good now/
9 days ago
That's nice to know! If you want to come back to Railpack, I would suggest you remove .bun-version... and just set the version on the packageManager field, It may be conflicting with the other definitions you have. You can also try regenerating your lock file.
I just deployed a bun 1.3.14 app (same as yours) and the only place I have it defined is in the packageManager field.
Status changed to Awaiting User Response Railway • 9 days ago
Status changed to Awaiting Conductor Response Railway • 8 days ago
8 days ago
Hello,
We had intermittent connectivity issues to Github, should be resolved now.
Status changed to Awaiting User Response Railway • 8 days ago
a day ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 1 day ago