We've pulled builder-vtzmis out of rotation, so your next build will land on a different machine. Your current build is stuck on it and won't recover, so push a commit or hit redeploy to kick off a fresh one.

Thanks! And what is my recourse in the future should this happen again? For context I've ran into platform instability previously where my business was fully blocked until some manual intervention like this could happen https://station.railway.com/support/service-unresponsive-cannot-redeploy-or-8b6f9f8a

When a build is stuck with no progress, cancel that deployment and redeploy. Each build is independently scheduled, so a fresh one will land on a different machine. That is the fastest self-serve path to unblock yourself while we sort out the underlying builder.

I think builder-cbjopk is stuck as well

Hi - just wanted to let you know we are investigating. Initial indications are that it doesn't look like this is an issue with the builder after all. The one we pulled earlier had not problems other than with your build and the same is true now of this one. I'm looking to see if we can understand what might be going on.

We've narrowed down where it stops. Your build step starts and then never finishes: the deploy sits on pnpm run --filter=@sidekick/server build, and that step never reports back, while everything else on the machine keeps completing normally around it. That's why the builder kept looking healthy. Only that one step is stuck.

One thing inside that step looks worth a look on your end. We already run pnpm install with a frozen lockfile as its own separate step, but your build command then does more dependency work of its own, removing 289 packages and downloading others, before tsup runs. It goes quiet right after that, and before tsup prints anything.

We haven't proven that's the cause, so treat it as a lead rather than an answer. If your build script does kick off an install of its own, try calling tsup directly from that step. That would sidestep the dependency work entirely and tell us a lot either way.

In the meantime, a hung build doesn't block a new one, so if a build goes quiet you can push again straight away rather than waiting it out.

Also worth correcting: redeploying won't reliably move you to a different machine. Builds for a given service keep returning to the same one. But again, the problem wasn't the builder.