firebase-tools: Error: TIMEOUT: Port 8080 on localhost was not active within 30000ms

I got the emulators running again by specifying host as “127.0.0.1” instead of the default “localhost”. I have no idea what changed that caused it to stop working on localhost. All I did was modify firebase.json like so to add host

 "emulators": {
        "auth": {
            "port": 9099,
            "host": "127.0.0.1"
        },
        "functions": {
            "port": 5001,
            "host": "127.0.0.1"
        },
        "firestore": {
            "port": 8080,
            "host": "127.0.0.1"
        },
        "hosting": {
            "port": 5001
        },
        "ui": {
            "enabled": true
        },
        "pubsub": {
            "port": 8085,
            "host": "127.0.0.1"
        },
        "storage": {
            "port": 9199,
            "host": "127.0.0.1"
        }
    }

As @stansotn mentioned, downgrade to 16 node work for me too. Catalina (10.15.7), tools - 9.22.0

brew unlink node
brew install node@16
brew link --overwrite node@16

any news on this? I am getting this issue as well when importing a large data set on start up

Same issue here when I run firebase emulators:start --only firestore --import=./backupfolder

i emulators: Starting emulators: firestore i firestore: Detected non-emulator Firestore export at backupfolder i firestore: Importing data from backupfolder/mybackup.overall_export_metadata i firestore: Firestore Emulator logging to firestore-debug.log i emulators: Shutting down emulators. i firestore: Stopping Firestore Emulator i hub: Stopping emulator hub

Error: TIMEOUT: Port 8080 on localhost was not active within 30000ms

As extra information that might help contributors (via @irving-luna input): I noticed that Homebrew updated node recently. Very very likely this issue indeed only occurs on node 17. Would be great if someone can confirm.

Downgrading to node 16 resolved the issue for me. Arch Linux (for search engines)

firebase emulators:start --only firestore works for me fine but when try to import the database, I’m getting the Timeout error. The database is large, my guess is that import is taking to long.

So I was fighting with that thing for some time checking every possibility and the I did

npm install -g firebase-tools

and surprise surprise it started working 🤷 why bits me but maybe it will help someone

Closing since downgrading to Node.js 16 seems to be a good workaround. Feel free to comment if you have more information or if this problem still persists when Node.js 18 becomes the new stable release.

For people running firebase emulators:start with the --import flag on large data sets like @huydinhle and @nolafs: my suggestion would be to not use --import but store whatever data store you have in a JSON file and import that after the emulators are running using a custom made population script. Your development flow would then to simply run this population script (each time) after starting the emulator. That way the importing process can take as long as you want and you could even add a nice progress bar as a bonus 😉. Note that you likely also need a small script to dump the firestore data to that JSON file in the first place. Only other workaround there is to fork firebase-tools and adapt the timeout in the source code here https://github.com/firebase/firebase-tools/blob/0be4074d717c0e58f36ffe5b0cdc09cffe869f1f/src/emulator/portUtils.ts#L142

Closing #3482 and opening #3483 just for hardcoding the timeout to 60 secs.

Can confirm that adding the host per @AndrewMorsillo’s suggested solution worked for me while using Node v17.0.1.

@AndrewMorsillo Try running the command with admin privileges.

sudo firebase emulators:start --only firestore

@dave-k when you say “unchanged project” do you mean this was working before and has since stopped? I haven’t seen an error like this on macOS yet, could you try two things:

1. I don’t think anyone on our team is using Node 14 yet, most of us are on 12 or below. Does changing your Node version change anything?
2. If you change the host for the Firestore emulator to 0.0.0.0 instead of localhost does that change anything? You can set this in firebase.json alongside the port.

Can’t test with <100mb, but with 750mb it’s still reproducible. Also, is there a way to increase the timeout? Idc if I have to wait an hour as long as it works. I’m just using the emulator to look at backups and afaik there is no way to “shrink” them by filtering for only the collections I’m interested in.

EDIT: So apparently, when running without export JAVA_TOOL_OPTIONS="-Xmx4g", it will throw a heap error. When setting the JAVA_TOOL_OPTIONS variable to 4g, it would throw no error and time out. When running the jar directly, it will throw a heap error.

Solution: Increase to 8g, no more timeout. Probably doesn’t scale very well, but for my usecase with 750gb it seems to work…

Just FYI same behavior on Windows machine with latest firebase tool

node -v
v18.5.0

firebase --version
11.2.2

Adding "host" : "127.0.0.1" allowed to start emulator, but UI still not working. Message below appears each time i’m trying to reach emulator’s UI.

[2022-07-13T12:51:39.938Z] u [FetchError]: request to http://localhost:4400/emulators failed, reason: connect ECONNREFUSED ::1:4400
    at ClientRequest.<anonymous> (C:\Users\User\.cache\firebase\emulators\ui-v1.7.0\server.bundle.js:326:16909)
    at ClientRequest.emit (node:events:537:28)
    at Socket.socketErrorListener (node:_http_client:465:9)
    at Socket.emit (node:events:537:28)
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  type: 'system',
  errno: 'ECONNREFUSED',
  code: 'ECONNREFUSED'
}
 {"metadata":{"emulator":{"name":"ui"},"message":"u [FetchError]: request to http://localhost:4400/emulators failed, reason: connect ECONNREFUSED ::1:4400\n    at ClientRequest.<anonymous> (C:\\Users\\User\\.cache\\firebase\\emulators\\ui-v1.7.0\\server.bundle.js:326:16909)\n    at ClientRequest.emit (node:events:537:28)\n    at Socket.socketErrorListener (node:_http_client:465:9)\n    at Socket.emit (node:events:537:28)\n    at emitErrorNT (node:internal/streams/destroy:151:8)\n    at emitErrorCloseNT (node:internal/streams/destroy:116:3)\n    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {\n  type: 'system',\n  errno: 'ECONNREFUSED',\n  code: 'ECONNREFUSED'\n}\n"}}

[UPDATE] Extra strange, but I can reach http://localhost:4400/emulators via browser and see list of configured “nodes”.

Now I’m getting timeouts at 60 seconds instead of 30.

Update - calling the jar directly ended up working. All other methods timed out.

(internal bug reference: b/172852315)

Confirmed that https://github.com/firebase/firebase-tools/issues/2379#issuecomment-951884721 works. I’m on Windows 10 Pro machine with Node.js v17.2.0.

Hello there, I’m having a similar issue on MacOS Monterey with Node v17. Adding the host key to the configuration file fixed the startup, and gave me a possibility for the root cause of the issue. Indeed, I had the following line at the end of the my tests (to generate a firestore rules coverage report)

http.get(`http://localhost:${port}/emulator/v1/projects/${projectId}:ruleCoverage.html`, res => {
 // ...
})

This seems to crash as well ! Here’s what I got

Error: connect ECONNREFUSED ::1:8090
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1161:16)
Emitted 'error' event on ClientRequest instance at:
    at Socket.socketErrorListener (node:_http_client:447:9)
    at Socket.emit (node:events:390:28)
    at emitErrorNT (node:internal/streams/destroy:164:8)
    at emitErrorCloseNT (node:internal/streams/destroy:129:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -61,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '::1',
  port: 8090
}

Replacing localhost by 127.0.0.1 fixed it, but I think localhost now resolves to ::1(IPv6) instead of 127.0.0.1 (IPv4). Maybe that’s why the CLI thinks the emulator is not yet ready

Potentially linked to https://github.com/firebase/firebase-tools-ui/issues/332

This started happening to me as soon as I upgraded from v9.20.0 to v9.21.0.

edit: rolling back versions didn’t change anything. This just randomly started happening and now I can’t run firestore emulator at all. Even running the java command directly and waiting longer does not work. Also re-downloaded firebase-tools and the emulator packages.

I’ve been having this same problem the last few days out of the blue. I’m running firebase emulators:start --import=data and the output is:

i  emulators: Starting emulators: auth, functions, firestore, database, hosting
!  functions: The following emulators are not running, calls to these services from the Functions emulator will affect production: pubsub
!  Your requested "node" version "10" doesn't match your global version "12"
i  firestore: Importing data from C:\repos\proctr\data\firestore_export\firestore_export.overall_export_metadata
i  firestore: Firestore Emulator logging to firestore-debug.log
i  emulators: Shutting down emulators.
i  functions: Stopping Functions Emulator
i  firestore: Stopping Firestore Emulator
!  Firestore Emulator has exited upon receiving signal: SIGINT
i  hub: Stopping emulator hub

Error: TIMEOUT: Port 8080 on localhost was not active within 30000ms

This problem persists if I change the ports.

one probably odd question why

Because yarn test is the following script:

nx run-many --all --target=test --parallel --maxParallel 3

The above command is fairly complicated, and instead of duplicating it in multiple places, I’d rather centralize it into one place.

You are not currently authenticated so some features may not work correctly. Please run firebase login to authenticate the CLI. in my case it helped 🤷

This is unlikely to be the solution. It’s likely the issue is still there, and it’s just intermittent. I still haven’t set that, and yet everything is working for me again because I simply stopped running 2 build tasks at the same time on the machine, and limited it to one. That ensures the emulator starts up faster.