Nicer handling of expected errors in the browser console

[david-crespo]

We have the API client logging helpful info about errors to the browser console whenever we get one back from the API to make it easier for internal or external users to report problems that they run into. However, sometimes we get errors that are expected and don't indicate a problem. For example, during image upload, which is a big multi-step process, in order to make sure that the image name won't be rejected at the end, we make sure the name is available by trying to fetch that image name. In this case a 404 from the API is effectively a success response as far as the console logic is concerned.

In order to reassure somebody looking at the browser console that the error that they see logged is not a real error, I had the image upload logic print another message to the console saying "don't worry, the error that you just saw above is not a bug." But the small "don't worry" message is easy to miss after a big red error log. @paudmir ran into that in #3097.

In this PR, I took the errorsExpected indicator we were already using it to prevent the error from blowing up the page and plumbed it through down into the error logging bit. So that when the error is expected, we log it in a less scary-looking way. I also added a required string explanation and an error code so that we're not eating all errors, but only the kind of error that we actually expect. I considered not logging at all in the expected error case, but I like having it there in case someone sees the error in the network tab and wants an explanation.

Actual errors are unchanged.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
console	Ready	Preview	Feb 26, 2026 11:57pm