Proposal: handle SIGTERM by default to initiate graceful worker shutdown
メンテナーはふだん 1 日以内に返信
@eamsden がすでに取り組んでいます。
2026年10月8日 から。
評価
この issue はまだ評価されていません。
説明
Summary
A Temporal Ruby worker traps only the signals passed in shutdown_signals:, and Temporalio::Worker.run / run_all default that to [] — so by default no signal is trapped. On SIGTERM (Kubernetes pod stop, Cloud Run scale-down/redeploy, docker stop, systemd) the OS default applies and the process is terminated immediately, before the worker can stop polling or drain in-flight work.
Proposal: consider defaulting shutdown_signals to include SIGTERM (opt-out-able), so the common containerized case — stop polling → drain for graceful_shutdown_timeout → cancel — works without extra wiring. The mechanism already exists (Internal::Worker::MultiRunner traps the listed signals); only the default is empty.
Current workaround
Pass shutdown_signals: ["SIGTERM"] to Temporalio::Worker.run / run_all.
Precedent
The TypeScript SDK already does this: its Runtime installs handlers for SIGINT/SIGTERM/SIGQUIT/SIGUSR2 by default and calls shutdown() on every worker.
Trade-offs / open questions (why it is not already the default)
- A worker usually runs inside a larger process (HTTP server, DI host, other lifecycle). A library installing a process-global signal handler can conflict with the host application's own signal handling, so any default must be clearly opt-out-able and should no-op when a host framework already owns the signal.
- Default-on vs. an explicit opt-in flag?
- If added, match the TypeScript semantics and honor the existing grace/drain config.
Why this comes up
SIGTERM-before-SIGKILL is the standard stop protocol for Kubernetes, Cloud Run, ECS, docker stop, and systemd. Users commonly expect a worker to drain on SIGTERM without extra wiring, and it is a recurring support question (e.g. https://community.temporal.io/t/proper-way-to-shutdown-on-sigterm-sigint/5485).
One of a set of sibling issues on default SIGTERM handling across the SDKs that do not auto-handle it today (Go, Python, Java, .NET, Ruby, Rust). TypeScript already does; PHP delegates process lifecycle to RoadRunner.
- 主要言語
- Ruby
- スター
- 207
- フォーク
- 44
- 平均マージ
- 1日 14時間
- マージ済み PR（30日）
- 15
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
temporalio/sdk-ruby のほかの issue
-
[Bug] JSON payload decoding raises ArgumentError with json 3.x (JSON.parse options are keyword-only)対応中かも @chris-olszewski が 8 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
temporalio/sdk-ruby#595 · コメント 3 件 · 担当者 2 名 ·
メンテナーはふだん 1 日以内に返信
-
Enable concurrent payload visiting - Ruby対応中かも @jmaeagle99 が 1 日前に担当しました。 オープン
temporalio/sdk-ruby#616 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
External Payload Storage Foundation - Ruby対応中かも @jmaeagle99 が 5 日前に担当しました。 オープン
temporalio/sdk-ruby#614 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
[Bug] Exception in an unawaited Workflow::Future is silently swallowed, leaving the workflow stuck RUNNING対応中かも @GregoryTravis が 1 日前に担当しました。 オープンbug
難易度 3/5 半日 初心者へのやさしさ 40/100
temporalio/sdk-ruby#613 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
[Feature Request] Add thread lifecycle hook to `Worker::ThreadPool`対応中かも @GregoryTravis が 50 日前に担当しました。 オープンenhancement
temporalio/sdk-ruby#563 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
temporalio/sdk-ruby の issue をすべて見る
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
GantMan/jail-monkey#380 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
voxpupuli/puppet-wireguard#151 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
Search accepts any value for `requests_per_page` and `per_page`対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンbug f:search
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信