test(NODE-5295): assert bypass mongocryptd connection fails with ECONNREFUSED

[nbbeeken]

Description

What is changing?

Fixes an error match assertion on node 20

Is there new documentation needed for these changes?

What is the motivation for this change?

Double check the following

• Ran npm run check:lint script
• Self-review completed using the steps outlined here
• PR title follows the correct format: type(NODE-xxxx)[!]: description
  • Example: feat(NODE-1234)!: rewriting everything in coffeescript
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[nbbeeken]

Passing socks5-csfle

[baileympearson]

can we make the PR description a bit better? reduce error message match strictness is pretty vague and won't be much help in our commit history

[baileympearson]

Rather than hard-coding logic for different Node versions, why not inspect the error and search for ECONNREFUSED?

Suggested change

	expect(insertError, 'Error must contain ECONNREFUSED').to.satisfy(
	expect(inspec(insertError), 'Error must contain ECONNREFUSED').to.match(/.*ECONNREFUSED.*/)

[nbbeeken]

I would want to know if there was yet another shape that the error took, the information went missing from the message in node 20, we will return it to the message in some way in: https://jira.mongodb.org/browse/NODE-5296, added todos and updated the ticket

[baileympearson]

From our public docs about our errors:

It is our recommendation to use instanceof checks on errors and to avoid relying on parsing error.message and error.name strings in your code. We guarantee instanceof checks will pass according to semver guidelines, but errors may be sub-classed or their messages may change at any time, even patch releases, as we see fit to increase the helpfulness of the errors.

We don't guarantee error messages. The error information is still present, the error is just structured differently. I don't think preserving the exact error info is important and so checking that the error itself is the correct error type is sufficient.

[nbbeeken]

Oh I was not thinking about public API / semver, just usefulness, as in an error with no message is not helpful so I don't want the test to not know about changes to the message if that's the regex we're looking for, in all cases, once we fix the node20 situation