Unhandled promise rejection when connection refused about client-js HOT 3 CLOSED

Hey @jdconley, thanks for filing this issue.

I think I understand the scenario, but let me run it by you just to be sure:

When fetch encounters a network error, it rejects the promise instead of resolving with a non-okay status code. Our fetch call wasn't in a try/catch, so whenever you encountered a network error, the global unhandled rejection event was being triggered and showing up in your logs. I've created a PR to catch the promise rejection and then explicitly throw a new error. If this all sounds right, I'll get a patch out for you.

I can go back and patch version 6 as well if you'd like, or if you'd like to upgrade to version 7, there's just a slight change to the format of the second parameter in your example: from edgeHeaders to { headers: edgeHeaders }

from client-js.

If this all sounds right, I'll get a patch out for you.

That does sound about right, thanks. I just want to be able to know when an exception occurs so it can be handled. That could be through return codes or re-throwing. Up to your interface design. I think bubbling up the rejection makes sense in this case.

I can go back and patch version 6 as well if you'd like, or if you'd like to upgrade to version 7, there's just a slight change to the format of the second parameter in your example: from edgeHeaders to { headers: edgeHeaders }

I tried the new library but the breaking change with the module format made it difficult to upgrade. I had hundreds of compiler errors to fix. It's probably going to take hours to migrate our project to the new format so I didn't want to bite that off. I would prefer a patch to 6.x.

Thanks!

from client-js.

@jdconley v6.2.1 should have the change you need. Let me know if it does the trick and I'll close this out. Also, if you don't mind sharing more about the compiler errors you were seeing with the v7 switch to es modules, I'll see if it's anything we can address.

Cheers

from client-js.