Got: Promise not resolving after response successfully received

[hendotcat]

Hey, I have a tricky little issue I wanted to ask about. I've found myself in a weird little situation where got is successfully fetching a 200 response from a server and calling resolve(response) with the response body correctly at the bottom of as-promise.js, but the data for some reason never makes it back to the call site.

I've prepared a little example repo which reproduces the issue, and the relevant code is quoted below.

import * as got from 'got'

export async function onPostBuild(): Promise<void> {
  const promise = got('http://example.org')
  console.log(promise)
  setTimeout(() => console.log(promise), 2000)

  const html = await got('http://example.org')
  console.log(html)
}

After the two second timeout, the promise is visibly resolved in the console.log output.

| console.log(promise) | setTimeout(() => console.log(promise), 2000) |
|---|---|
| | |

However, for some reason, the await got() version in the 2nd block of code hangs forever. The data has been fetched but for some reason the flow of control breaks down while returning it back up the stack to my function. I've tried .then() as well and had no luck with that either.

Is there some obvious mistake in my usage of got here? I've been debugging this for at least two hours now and figured at this point it's probably helpful to have the question up for the sake of the future Google results even if I'm doing something really silly! 😇

[szmarczak]

Hmm... I've checked that on my local machine and on runkit too and I couldn't reproduce that.
Could you fill the bug template please? What's your Node version? What's the Got version?

[MorpheusXAUT]

I'm seeing a similar behavior when using Got in our TypeScript project.
Same as shown above, using const res = await got("example.com"); yields no result, but hangs indefinitely. On the contrary to @hensmith though, calling .then() did return a response as expected, just awaiting the returned promise somehow failed.

I'm seeing the issues in a project using:
Node: v8.15.0
Got: v9.6.0
TypeScript: v2.9.2
@types/got: v9.4.0
bluebird: v3.5.0

Our TypeScript target is es5 using the commonjs module, similar to the example code provided above. Promises are polyfilled globally using bluebird.

[szmarczak]

@MorpheusXAUT Thank you for the detailed information! 😃 Have you tried it without Bluebird?

[MorpheusXAUT]

Unfortunately, the rest of the project I've encountered the issue in depends on Bluebird promises, so removing them for the test would not be as trivial :smile:
I can put together a simple example project like @hensmith did using the rest of the dependencies described during this weekend though, if that'd be helpful!

[hendotcat]

oh wow!!! this prompted me to revisit the .then() approach and you're right! i made the following change to my example code and it fixed the issue! i think when i first tried this, i may have forgotten to return the promise or something!

-  const html = await got('http://example.org')
-  console.log(html)
+  return got('http://example.org').then(r => {
+    console.log(r.body)
+  })

im 100% satisfied with this workaround, and i hope it proves helpful for anyone else who shows up here after googling for this issue. thank you so much @MorpheusXAUT and @szmarczak ❤️

[szmarczak]

I'll check the Bluebird approach now.

[MorpheusXAUT]

@hensmith Good to see it at least behaves the same for you :smile: Using .then() and handling the result that way is definitely a workaround that works fine, however given the rest of our code, I'd personally try to avoid it and using await if possible. Furthermore, I'm curious as to why awaiting the promise doesn't work, when it does apparently return just fine as it's thenable...
I guess the awaiter generated by TypeScript when transpiling down to es5 might be causing some issues? :thinking:

@szmarczak Thanks for looking into this, appreciated! Let me know if you need any other information or tests from my side!

[szmarczak]

I'd personally try to avoid it and using await if possible.

That's not a good behavior though...

I believe it's Bluebird failure. I'll let you know when I have figured out what's wrong :)

[szmarczak]

I can't reproduce with Bluebird: https://runkit.com/szmarczak/5c41aaa1b1379d001634494d

I'll try @hensmith's repo.

[szmarczak]

Unfortunately I couldn't reproduce it too: https://pastebin.com/raw/2vtaNA0L

[szmarczak]

@MorpheusXAUT

I can put together a simple example project like @hensmith did using the rest of the dependencies described during this weekend though, if that'd be helpful!

Of course! Any help is appreciated :)

You can also try upgrading to Node 10.

[MorpheusXAUT]

Alright, I'll try to set up a small sample to reproduce it tomorrow or on Sunday 👍 Will post back here with results.

[szmarczak]

@hensmith @MorpheusXAUT Any updates on how to reproduce the issue?

[MorpheusXAUT]

Sorry, been away all weekend, will try to put something together tonight or tomorrow latest!

[muliyul]

I was experiencing the same issue with bluebird ^3.5.3

[szmarczak]

@muliyul Are you able to reproduce the issue? Have you tried running it with native Promises?

[muliyul]

@szmarczak not able to reproduce with neither impl. (which is odd because I do remember bumping into this)

[MorpheusXAUT]

@szmarczak I actually didn't manage to set up a standalone repository reproducing the issue we're seeing. I'll have to take another look at our project setup at work tomorrow to try and see what other differences we have.

[szmarczak]

@MorpheusXAUT Ok. Let us know if the issue still persists when using native Promises.

[szmarczak]

@MorpheusXAUT Heads up! It has been a month :P Any news?

[szmarczak]

Closing due to lack of response.

[fluffynuts]

I've just seen something similar -- don't mean to necro, but I've spent 2 days on this, so just in case someone else comes along with the same head-scratcher...

I've been upgrading a project from node 8 to node 12. It was using got ^10.7.0. The code is especially difficult to debug because it loads JavaScript from a database so debugging is environment-specific (and, as I say, a mission).

However, I was finding that my deployment at an Ubuntu 16 machine, using node 12.16.1 (and 12.16.2) via NVM, would hang up on requests using got. Everything worked fine on a Windows host, as well as on an Ubuntu 16 host under WSL. I could perform a manual https request fine on the problematic machine. I could also perform the same query if I didn't include our custom authentication header (but I would get 401 responses, of course)

So it seems that this combination is a recipe for sadness:

• got 10.x
• node 12.x
• Ubuntu 16
• requests with custom headers

Upgrading to ^11.0.2 resolved the issue.