Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[WORKFLOW SDK FEATURE REQUEST] Retry WaitForInstanceCompletion/Start on a server-sent CANCELLED

Abierto
  • ¿Algo no está bien?
#1,246 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend, distributed-systems

Línea de trabajo

Start in dapr/ext/workflow/_durabletask/client.py around lines 335-349 and the matching retry logic in aio/client.py. Read the three cancellation tests in tests/ext/workflow/durabletask/test_orchestration_wait.py and test_client_async.py, then confirm the intended retry and timeout behavior with maintainers. Done means both clients re-issue eligible waits after server CANCELLED responses while preserving caller deadlines and the updated tests pass.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

dapr-ext-workflow kind/enhancement

Proposal

wait_for_workflow_completion and wait_for_workflow_start (sync and aio) should re-issue WaitForInstanceCompletion / WaitForInstanceStart when the server ends the call with CANCELLED and the caller's own timeout hasn't expired. Today that status reaches the caller as an error, even though the workflow is still running. This asks maintainers to decide on the behaviour first, because it reverses assertions added in #1112. It's a proposal, not a PR.

Why the server sends CANCELLED

When daprd shuts down or restarts mid-wait (rollout, pod restart, hot-reload, a config change that restarts the runtime), the actors router cancels every in-flight call it tracks. The wait then returns CANCELLED "context canceled", even though the caller is still waiting. The mechanism and a repro are in dapr/dapr#10566.

Reproduced against native daprd 1.18.0:

  • a 60 s workflow with wait_for_workflow_completion(id) and no timeout returns normally;
  • the same run with daprd sent SIGTERM about 10 s in fails with StatusCode.CANCELLED "context canceled".

Why retrying is safe

  • A blocking unary call only gets CANCELLED from the server. The sync client can't cancel it mid-flight, and in the aio client a caller's cancellation raises asyncio.CancelledError, not AioRpcError. A client-side deadline shows up as DEADLINE_EXCEEDED, which already maps to TimeoutError.
  • The wait only reads state, so re-issuing it is idempotent. It returns straight away if the workflow already finished.

What would change

Relationship to the runtime fix

The proper fix is in daprd: return UNAVAILABLE in this case (dapr/dapr#10566). The SDK already retries UNAVAILABLE. This change would protect users on current and older runtimes until that ships, and it would still help afterwards with proxies that reset the stream.

Question for maintainers

Is it acceptable to treat a server-sent CANCELLED on these two waits as retryable, and change the #1112 tests? If yes, it's a small change in both clients plus tests.

Lenguaje dominante
Python
Estrellas
272
Forks
152
Merge medio
3 d 13 h
PR fusionados (30 d)
11

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dapr/python-sdk

Todos los issues de dapr/python-sdk

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.