spanner: requiring @google-cloud/spanner stops the process from exiting on SIGTERM/SIGINT
维护者通常 1 天内回复
@alkatrivedi 已经在做这个了。
开始于 2026年10月13日。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 78/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- nodejs, typescript
- 领域
- backend
调研方向
从 handwritten/spanner/src/index.ts 开始,该文件中注册了 SIGINT 和 SIGTERM 监听器,然后使用 npm install && npm test 运行链接的最小复现。确认存在和不存在 @google-cloud/spanner 时的进程行为;当加载该库不再阻止预期的信号关闭行为时,即表示完成。
由索引模型根据 Issue 内容生成。
描述
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.
- 主要语言
- TypeScript
- 星标
- 3.2k
- 派生
- 724
- 平均合并
- 2 天 10 小时
- 30 天内合并 PR
- 145
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
googleapis/google-cloud-node 的其他 Issue
-
难度 1/5 1 小时以内 新手友好度 82/100
googleapis/google-cloud-node#9723 ·
维护者通常 1 天内回复
-
google-auth-library: JWT with a JSON keyFile signs without iss since 10.6.1 (invalid_grant: account not found)可能已有人在做 @Marinski 于 27 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 85/100
googleapis/google-cloud-node#9469 ·
维护者通常 1 天内回复
-
priority: p1 samples type: bug
难度 2/5 1-3 小时 新手友好度 68/100
googleapis/google-cloud-node#9367 ·
维护者通常 1 天内回复
-
bug(gapic-node-processing): setOnlyDefaultSystemTests incorrectly matches substring on absolute path可能已有人在做 @rootkiller6788 于 21 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 88/100
googleapis/google-cloud-node#9342 · 2 条评论 ·
维护者通常 1 天内回复
-
TransferManager uploadFileInChunks does not error when aborted可能已有人在做 @Om-singhaI 于 64 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 84/100
googleapis/google-cloud-node#9193 ·
维护者通常 1 天内回复
查看 googleapis/google-cloud-node 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 76/100
awslabs/visual-asset-management-system#804 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
restatedev/sdk-typescript#813 ·
-
bug desktop P1 session XS
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
Merit-Systems/x402scan#1312 ·
-
type:bug
难度 2/5 1-3 小时 新手友好度 78/100
Azure/apiops-cli#331 ·
维护者通常 3 天内回复