fix: runBuild should exit with 1 on unexpected errors (when watch mode is disabled) #754
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(Maybe) partially addresses: #740.(EDIT: OP seems to have a different issue, the build does go through without errors even though the worker is somehow malformed).I've encountered a similar issue on my own, we had an import of a file with multiple locale-specific characters, and it was causing the
.vercel/output/functions/<page-name>.func/index.js
to contain a blurb likewhich caused the build logs to output
I wasn't able to come up with a simple repro on this specific issue (and it looks more like something our project was doing wrong), but it's fairly simple to test that if
acorn's parse()
throws insidegetFunctionIdentifiers()
, the deploy fails and the exit code is 0 (which means CI or a command that does&& pnpm run:deploy
would carry on with a broken build).In our case, it was creating the same defect as OP has on #740, a deployment successfully goes out but all paths return 404 (even homepage) as something goes wrong building the worker's code.
I'm assuming there might be N different reasons why a build can fail at this stage, but if they're all going through the unexpected error path, I'd assume we'll always want to signal exit 1 to prevent deployments to continue broken.