Proposal: handle SIGTERM by default to initiate graceful worker shutdown
Mantenedores costumam responder em até 1 dia
@eamsden já está trabalhando nisso.
Desde 8/10/2026.
Avaliação
Esta issue ainda não foi avaliada.
Descrição
Summary
A Temporal Python worker installs no OS signal handler by default, so when the process receives SIGTERM (Kubernetes pod stop, Cloud Run scale-down/redeploy, docker stop, systemd), the OS default disposition applies and the process is terminated immediately — before the worker can stop polling or drain in-flight work. In-flight activities are abandoned and retried server-side after their timeouts. (Python installs a handler for SIGINT but deliberately leaves SIGTERM at the OS default.)
Proposal: consider initiating the worker's existing graceful-shutdown path on SIGTERM by default (opt-out-able), so the common containerized case — stop polling → drain for graceful_shutdown_timeout → cancel — works without extra wiring.
Current workaround
loop.add_signal_handler(signal.SIGTERM, ...) to trigger await worker.shutdown() (or to exit an async with worker: block).
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.
- Linguagem predominante
- Python
- Estrelas
- 1.2k
- Forks
- 269
- Merge médio
- 1d 11h
- PRs com merge (30d)
- 64
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de temporalio/sdk-python
-
[Bug] async def update validator is accepted but never runs, so every update is acceptedTalvez já em andamento @avanish-garg assumiu hoje. Abertabug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
temporalio/sdk-python#2004 ·
Mantenedores costumam responder em até 1 dia
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
temporalio/sdk-python#496 ·
Mantenedores costumam responder em até 1 dia
-
[Bug] Retried `ActivityHandle.terminate()` can fail after the activity is already terminatedTalvez já em andamento @maciejdudko assumiu hoje. Aberta
temporalio/sdk-python#2008 · 1 responsável ·
Mantenedores costumam responder em até 1 dia
-
[Bug] Annotated constraints and validators on workflow/activity/handler parameters are ignored by the Pydantic data converterTalvez já em andamento @tconley1428 assumiu hoje. Abertabug
temporalio/sdk-python#2006 · 1 comentário · 1 responsável ·
Mantenedores costumam responder em até 1 dia
-
Cloud CI Skips Nexus TestsTalvez livre de novo @tconley1428 assumiu há 72 dias e não há nenhum pull request aberto. Aberta
temporalio/sdk-python#1704 · 1 responsável ·
Mantenedores costumam responder em até 1 dia
Todas as issues de temporalio/sdk-python
Issues semelhantes
-
[oblt-aw][autodoc] Update workflow docs for gh-aw v0.92.5 and detector permission scopeTalvez já em andamento @github-actions assumiu hoje. Aberta
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 88/100
Mantenedores costumam responder em até 1 dia
-
enhancement
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
Mantenedores costumam responder em até 1 dia
-
feat(ide): VS Code access through the shipped MCP server (config doc and tool-list smoke test)Abertaroadmap-100
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
Mantenedores costumam responder em até 1 dia
-
comp/tools P2 tool/browser tool/file type/bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
NousResearch/hermes-agent#143418 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
python-hyper/uritemplate#164 ·