[CLI crashes with libuv assertion after printing its result - exit code then reads as failure]
CLI Version: firebase-tools 15.30.0
Platform: Windows 11 Pro (10.0.26200), Node v24.18.0
Node Version: v24.18.0
Steps to reproduce:
firebase login
- Run a subcommand that prints a result and exits, e.g.
firebase apps:sdkconfig <app-id>
Expected behavior
Process exits 0 after printing the result.
Actual behavior
Process prints its full result to stdout, then crashes:
Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 94
Exit code is then 127, even though the command's own output shows it completed
successfully. Measured in one session, same binary, same login:
| subcommand |
assertion fires |
exit code |
login |
yes |
n/a (interactive) |
apps:sdkconfig |
yes |
127 |
projects:list |
no |
0 |
groups:create |
no |
0 |
testers:add |
no |
0 |
testers:list |
no |
0 |
Non-deterministic across otherwise-similar subcommands in the same process/session, which
suggests a race in libuv handle teardown on process exit (Windows-specific: src\win\async.c)
rather than anything about the individual command.
Impact
Any caller that gates on $LASTEXITCODE (or any exit-code check) cannot tell a real failure
from this teardown crash - a command that fully completed and printed its result can still be
read as failed, which for an upload/publish command silently corrupts release tooling built on
top of the CLI.
[CLI crashes with libuv assertion after printing its result - exit code then reads as failure]
CLI Version: firebase-tools 15.30.0
Platform: Windows 11 Pro (10.0.26200), Node v24.18.0
Node Version: v24.18.0
Steps to reproduce:
firebase loginfirebase apps:sdkconfig <app-id>Expected behavior
Process exits 0 after printing the result.
Actual behavior
Process prints its full result to stdout, then crashes:
Exit code is then 127, even though the command's own output shows it completed
successfully. Measured in one session, same binary, same login:
loginapps:sdkconfigprojects:listgroups:createtesters:addtesters:listNon-deterministic across otherwise-similar subcommands in the same process/session, which
suggests a race in libuv handle teardown on process exit (Windows-specific:
src\win\async.c)rather than anything about the individual command.
Impact
Any caller that gates on
$LASTEXITCODE(or any exit-code check) cannot tell a real failurefrom this teardown crash - a command that fully completed and printed its result can still be
read as failed, which for an upload/publish command silently corrupts release tooling built on
top of the CLI.