firestore does not work properly in from node 18

[daenamkim]

[REQUIRED] Environment info

firebase-tools:

• 11.29.1

Platform:

• macOS 13.3.1
• linux (ubuntu-latest of GitHub CI)

[REQUIRED] Test case

See an attached file: firebase-tools-report.zip

[REQUIRED] Steps to reproduce

See an attached file: firebase-tools-report.zip

[REQUIRED] Expected behavior

Should be success (since it has been passed until node 16)

Out of curiosity, I see this when I did not put runtime in firebase.json, does this mean higher than 16 is not supported? Since I have tested node 17 and 18, both did not work.

⬢  functions: Failed to load function definition from source: FirebaseError: package.json in functions directory has an engines field which is unsupported. Valid choices are: {"node": 10|12|14|16}

[REQUIRED] Actual behavior

    1) "after each" hook: afterEach for "should set the admin claim when user claim is created 1"

  1 passing (38ms)
  1 failing

  1) "after each" hook: afterEach for "should set the admin claim when user claim is created 1":
     Error: connect ECONNREFUSED ::1:8580
      at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16)

[daenamkim]

Interesting thing I found is that it has been passed in node 20! But I don't want to use node 20 at the moment so it would be happy to use node 18.

[daenamkim]

Any update for this? :bow:

[aalej]

Hi @daenamkim, apologies for the delay and thanks for the MCVE and the detailed description of the issue you're encountering. I was able to replicate the issue you mentioned, when I tried running yarn test it fails when using Node v18, but not when using Node v16 or v20. Also, when I tried not setting a specific value for the runtime, I also encountered the same error message.

I’ll notify our team about these issues so that they can provide more context and investigate what might be causing this.

[christhompsongoogle]

Hi daenamkim,

After investigating with aalej and lahirumaramba this is a known issue where Node's 18 defaults to ipv6 address resolution: https://github.com/node-fetch/node-fetch/issues/1624

One solution proposed in that bug is setting the following in your App: dns.setDefaultResultOrder('ipv4first')

That will work around the issue in the short term.

The solution we've taken in the emulator suite is to use an explicit IP address like 127.0.0.1 instead of localhost. In this case I need to investigate the hostname resolution since it's not obvious at first glance where it's deriving "locahost" from.