spanner: requiring @google-cloud/spanner stops the process from exiting on SIGTERM/SIGINT
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- nodejs, typescript
- Domain
- backend
Research direction
Start with handwritten/spanner/src/index.ts, where the SIGINT and SIGTERM listeners are registered, and run the linked minimal reproduction with npm install && npm test. Confirm the process behavior with and without @google-cloud/spanner; done means loading the library no longer prevents the expected signal shutdown behavior.
Written by the indexing model from the issue text.
Description
Please make sure you have searched for information in the following guides.
- Search the issues already opened: https://github.com/GoogleCloudPlatform/google-cloud-node/issues
- Search StackOverflow: http://stackoverflow.com/questions/tagged/google-cloud-platform+node.js
- Check our Troubleshooting guide: https://github.com/googleapis/google-cloud-node/blob/main/docs/troubleshooting.md
- Check our FAQ: https://github.com/googleapis/google-cloud-node/blob/main/docs/faq.md
- Check our libraries HOW-TO: https://github.com/googleapis/gax-nodejs/blob/main/client-libraries.md
- Check out our authentication guide: https://github.com/googleapis/google-auth-library-nodejs
- Check out handwritten samples for many of our APIs: https://github.com/GoogleCloudPlatform/nodejs-docs-samples
- Check the API's issue tracker: https://cloud.google.com/support/docs/issue-trackers
Library Name
@google-cloud/spanner
A screenshot that you have tested with "Try this API".
Not API related
Link to the code that reproduces this issue. A link to a public Github Repository or gist with a minimal reproduction.
https://gist.github.com/wildan2711/1630361a07bd531792be280519d8e3fa
A step-by-step description of how to reproduce the issue, based on the linked reproduction.
Runnable reproduction: https://gist.github.com/wildan2711/1630361a07bd531792be280519d8e3fa (npm install && npm test)
Minimal version:
// repro.js
require('@google-cloud/spanner');
console.log('SIGTERM listeners:', process.listenerCount('SIGTERM'));
setInterval(() => {}, 1000); // anything that keeps the event loop alive, e.g. an HTTP server
node repro.js &
kill -TERM $! # process keeps running
kill -INT $! # still running; only SIGKILL stops it
Remove the require line and the same script exits on SIGTERM as expected.
A clear and concise description of what the bug is, and what you expected to happen.
Requiring @google-cloud/spanner makes a long-running Node.js process ignore SIGTERM and SIGINT. When the module loads, it registers process.on('SIGINT') and process.on('SIGTERM') listeners in handwritten/spanner/src/index.ts that run the metrics cleanup() but never exit or re-raise the signal. The process then keeps running until it gets SIGKILL. This applies even if no Spanner client is ever created. In practice, Cloud Run, GKE and App Engine instances run until the end of the shutdown grace period instead of stopping, docker stop and process managers leave orphaned processes holding their ports, and Ctrl+C doesn't stop a dev server.
Expected: loading the library doesn't change how the process responds to signals. A process that would exit on SIGTERM or SIGINT without @google-cloud/spanner should still exit with it.
A clear and concise description WHY you expect this behavior, i.e., was it a recent change, there is documentation that points to this behavior, etc. **
- It's a regression. 8.0.0 registers no signal listeners and the process exits normally. The listeners first appear in 8.1.0 and are still present in 9.0.0 and on
main. We noticed when upgrading from 6.x to 8.6.0: our services stopped shutting down on SIGTERM. - Node.js documents this effect. Per the signal events docs, "SIGTERM and SIGINT have default handlers on non-Windows platforms that reset the terminal mode before exiting with code 128 + signal number. If one of these signals has a listener installed, its default behavior will be removed (Node.js will no longer exit)." So any listener that doesn't exit stops the process from shutting down.
- The code's own comment says the process should exit. It reads
// For signals (let process exit naturally), which shows the listeners were meant to flush metrics without blocking shutdown. But a process with an open server, socket or timer never exits "naturally", so in practice they block it. - Libraries generally shouldn't own process signals. Shutdown on SIGTERM and SIGINT belongs to the application or its framework, which may need its own graceful-shutdown logic. A dependency that silently disables the default makes that impossible to see, and the only workaround is removing the listeners by hand.
- Dominant language
- TypeScript
- Stars
- 3.2k
- Forks
- 723
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 172
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from googleapis/google-cloud-node
-
google-auth-library: JWT with a JSON keyFile signs without iss since 10.6.1 (invalid_grant: account not found)Possibly taken @Marinski claimed this 10 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
googleapis/google-cloud-node#9469 ·
Maintainers usually reply within 1 day
-
priority: p1 samples type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
googleapis/google-cloud-node#9367 ·
Maintainers usually reply within 1 day
-
bug(gapic-node-processing): setOnlyDefaultSystemTests incorrectly matches substring on absolute pathPossibly taken @rootkiller6788 claimed this 5 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
googleapis/google-cloud-node#9342 · 2 comments ·
Maintainers usually reply within 1 day
-
TransferManager uploadFileInChunks does not error when abortedPossibly taken @Om-singhaI claimed this 48 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
googleapis/google-cloud-node#9193 ·
Maintainers usually reply within 1 day
-
google-auth-library: getErrorFromOAuthErrorResponse() copies stack as non-writable, breaking error decoration in consumersPossibly taken @Om-singhaI claimed this 48 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
googleapis/google-cloud-node#9155 ·
Maintainers usually reply within 1 day
All issues in googleapis/google-cloud-node
Similar issues
-
check:passed streams:add
Difficulty 1/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 2 days
-
beta technical-medium ui
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
walletbeat/walletbeat#1625 ·
Maintainers usually reply within 1 day
-
[Good First Issue]: Add unit tests for NetworkVersionInfoPossibly taken A pull request linked to this issue is open or already merged. OpenGood First Issue hacktoberfest
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
hiero-ledger/hiero-sdk-js#4489 ·
Maintainers usually reply within 1 day
-
[Bug] The clients language filter cannot select the rows the page labels as unknownPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
apache/rocketmq-dashboard#6103 ·
Maintainers usually reply within 4 days
-
Bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
payloadcms/payload#18652 ·
Maintainers usually reply within 1 day