Dapr
v1.17.9Orchestration & Managementv1.17.9 fixes a targeted bug where workflows using Azure Cosmos DB as their actor state store get permanently stuck in a purge loop when the customStatus row is absent.
breakingUpgrade immediately if using Cosmos DB for workflow state
Any deployment using state.azure.cosmosdb as the workflow actor state store is at risk. Affected workflows never get purged past their TTL, and the scheduler fires a purge attempt every second forever — burning CPU, generating log noise, and inflating your dapr_runtime_workflow_operation_count{status=failed} metrics. Upgrade to 1.17.9 and restart sidecars; stuck workflows recover on the next retention reminder fire automatically. No manual cleanup needed after upgrade.
enhancementCheck metrics now to assess blast radius before upgrading
Before upgrading, query dapr_runtime_workflow_operation_count with labels operation=purge_workflow and status=failed. A non-zero and growing count on a Cosmos DB deployment confirms you have stuck workflows. This tells you how many workflows will self-heal post-upgrade and gives you a clear before/after signal to verify the fix took effect.
主な変更 (5)
- Workflow purge now tracks whether customStatus was actually persisted before including its delete in the Cosmos transactional batch
- Affected workflows on Cosmos DB recover automatically after sidecar upgrade — no manual scheduler job deletion required
- Root cause: Cosmos DB's atomic batch semantics reject a NotFound delete, rolling back the entire purge transaction
- Retry policy of 1s/forever meant stuck workflows were generating noisy metric increments and log spam indefinitely
- Fix applies to workflows upgraded from pre-customStatus daprd versions, manually cleaned up, or that never advanced past initial state