Surface local proxy errors during app dev#7535
Draft
isaacroldan wants to merge 7 commits into
Draft
Conversation
Makes the local reverse proxy's failure modes visible instead of silent:
- Wrap server.listen in a real promise so a failed bind (EADDRINUSE, etc.) rejects through the dev runner instead of crashing Node via an uncaught 'error' event. server.listen returns the Server synchronously, so the previous await was a no-op.
- Move the 'Proxy server started' log to after listen actually resolves so it stops printing on failed binds.
- Add a runtime server.on('error') handler that warns through the proxy stream instead of crashing the process.
- Warn (not just outputDebug) when an HTTP request has no matching rule and the proxy 500s the caller.
- Warn before socket.destroy() when a websocket upgrade has no matching rule, instead of dropping it silently.
The post-bind server.on('error') handler previously warned once and returned, leaving a dead proxy server while the dev session kept running. Subsequent requests would fail with ECONNREFUSED at the client with no further indication from the CLI.
Keep startProxyServer running for the lifetime of the dev session: resolve on the abort signal, reject when the server emits a runtime error so ConcurrentOutput tears the whole session down instead of leaving the user with one warning and a silently broken proxy.
Focus the messages on what happened and what to check, not on internal concepts like 'rules', 'forwarding', or 'targets'. Special-case EADDRINUSE and EACCES at bind time so the most common port-collision failure tells the user how to recover instead of dumping a Node errno.
Drop the prose advice and stick to the facts: every message names the component ('local proxy') and states what failed, on one line. The component name makes each line stand on its own even if the log prefix is missed; the format is consistent so the user can pattern-match across messages.
The HTTP/WS forward error callbacks and the 500 response body were rewritten earlier in this PR; revert them to their original wording. The new messages I'm keeping are only the ones for paths that were previously silent: unmatched HTTP/WS routes, post-bind runtime errors, and bind-time error translation.
Align the new warnings and bind-error messages with the format already used in the outputDebug block for unmatched paths, so all proxy-related diagnostics share the same prefix and tone.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
WHY are these changes introduced?
Fixes #0000
WHAT is this pull request doing?
How to test your changes?
Post-release steps
Checklist
patchfor bug fixes ·minorfor new features ·majorfor breaking changes) and added a changeset withpnpm changeset add