Skip to content

feat: no match return 501 response#2868

Merged
mikicho merged 6 commits into
betafrom
Michael/fix-2558
May 30, 2025
Merged

feat: no match return 501 response#2868
mikicho merged 6 commits into
betafrom
Michael/fix-2558

Conversation

@mikicho
Copy link
Copy Markdown
Member

@mikicho mikicho commented May 25, 2025

  1. Return a response instead of throwing an error. This approach is beneficial because HTTP clients expect either a response or the request to be destroyed. Previously, with the older implementation of nock, we simply threw an error, which resulted in unspecified errors. (disableNetConnect() / "Not allow net connect" errors are swallowed up #884, disableNetConnect should return an IncomingMessage #2211)
  2. Return 501 instead of 400 as discussed here.

@gr2m Before investing time in adjusting the tests, WDYT about this?
@simlu I'd also love your thoughts here.

Resolves #2558

@mikicho mikicho linked an issue May 26, 2025 that may be closed by this pull request
2 tasks
@gr2m
Copy link
Copy Markdown
Member

gr2m commented May 27, 2025

Before investing time in adjusting the tests, WDYT about this?

I agree this is the better approach 👍🏼

@simlu
Copy link
Copy Markdown

simlu commented May 27, 2025

This is an unexpected error case that typically happens (for me) when code has changed and test recordings need to be fixed. So it really depends on "who" is doing the testing here: client or server - in most cases it is going to be both.

If it's the client, a 5xx makes perfect sense. If it's the server, a "crash" would work better, however then the client couldn't debug. Returning an explicit 5xx means that we would need to intercept, log and/or throw it on the server. Seems very reasonable, especially since we are already returning a 404 currently.

Alternative would be to do a config flag to switch between an explicit 5xx and crash. But I don't see a need for that currently.

I'm happy with changing this to a 5xx. Should allow me to get rid of some hacks for node-tdd.

tldr; Yes, this looks good 👍

@mikicho
Copy link
Copy Markdown
Member Author

mikicho commented May 27, 2025

Thanks to both of you! I'll continue in this direction.

@simlu, what do you mean by "who" makes the request? As I see it, nock acts like a remote server (for most of the time).


for most of the time

To elaborate on this.. we can separate the request into two parts:

  1. What the code does from the http.get (or any other client) until the request is written to the socket
  2. The interception logic that returns the mocked response.

In the first part, nock needs to think like a client, and in the second, like a server, which is most cases because in v14 we mocked as little than possible.

@simlu
Copy link
Copy Markdown

simlu commented May 29, 2025

@simlu, what do you mean by "who" makes the request? As I see it, nock acts like a remote server (for most of the time).

Some of the use cases that are supported by node-tdd are not exactly the vanilla use cases for nock. I think wrt this ticket, we don't really need to worry about them.

What you've written down definitely makes sense and think you're good to continue with this change-set!

@mikicho mikicho requested review from Uzlopak and gr2m May 29, 2025 22:07
@mikicho mikicho merged commit 7bb9716 into beta May 30, 2025
11 checks passed
@mikicho mikicho deleted the Michael/fix-2558 branch May 30, 2025 22:20
@github-actions
Copy link
Copy Markdown

🎉 This PR is included in version 15.0.0-beta.3 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Return 500 instead of 404

3 participants