gray tangle
Hello,
We are using DAPR 1.16.14 in production.
We are using the Workflow component of DAPR and are experiencing some difficulties.
We have several workflows that are restarting for an unknown reason, and we don't understand the errors.
Here is an excerpt of logs from AppInsight.
We are sometimes completely stuck, and the only solution is to delete the PVCs from the scheduler and recreate them.
Thnaks for your help...
stuck prawn
Asking the obvious question, do you have logs for your activity that is failing? I am guessing you have a retry policy that retries 4 times? Which is why you see the four attempts, but since all had failed, your workflow fails
gray tangle
What surprises us is that we have a retry policy on Pub/Sub but not on workflows.
Event time 07/05/2026 15:44:44.262194 (Heure locale)
Name activity||tmscoreglobaldataintegrationtaskactivity
Response code 2
Successful request false
Response time 2.3 s
Custom Properties
otel.scope.name durabletask
otel.status_code STATUS_CODE_ERROR
service.name tmssta-3-12-0-alpha-454-task-runner
durabletask.task.instance_id d5f117772d394048bec0a731ae26feca
durabletask.task.name TmsCoreGlobalDataIntegrationTaskActivity
durabletask.type activity
durabletask.task.task_id 2
error operation aborted
stone marlin
Hi @gray tangle
What is the output to $ dapr wf history ... ?
Using the dapr CLI
red nexus
Hello,
I’m working with Laurent. One additional detail:
Actually, what we’re observing is that the activity gets restarted even though it’s still running.
In fact, all executions — the original one and all the restarted ones — run to completion in parallel.
It’s as if Dapr thinks the activity is no longer running or has crashed, so it starts it again.
stone marlin
@red nexus is scheduler being restarted/rolled during this time?
& also, which SDK are you using?
red nexus
@stone marlin
SDK 1.16.9 and no scheduler restarted
On the scheduler, we have a lot of log like :
time="2026-05-06T13:25:54.148263943Z" level=info msg="Adding a Sidecar connection to Scheduler for appID: ..." instance=... scope=dapr.scheduler.server.pool.loops.connections type=log ver=1.16.14
2026/05/06 13:25:54 Marking prefixes as undeliverable for one caller: stream closed by scheduler
Is this a problem ?
stone marlin
In which language?
This suggests the application pods are restarting
gray tangle
C#
Sorry, We use SDK dotnet 1.16.1 . In kubernetest, we use with sidecar in 1.16.9 but helm chart is 1.16.14
red nexus
In which language?
This suggests the application pods are restarting
That’s the strange part: there is no restart. In fact, this is confirmed by the fact that all the activities incorrectly launched in parallel run to completion.
In a normal setup, we shouldn’t be seeing these logs, right?
potent lintel
I would urge you to use the 1.17 version of the SDK
Don't use the versioning functionality since you're on the older runtime and it doesn't support it, but there were a bunch of workflow issues fixed in the SDK under the hood between 1.16 and 1.17 and I expect you would see many of these resolved.
gray tangle
Ok and we van use without any problems the SDK version 1.17 with the runtime 1.16 ?