Best Practice for Session Affinity with Graceful Worker Shutdown

[arvinx]

I am using session affinity for a long-running workflow to ensure my activities execute on the same worker. However, I’m facing an issue with graceful worker shutdowns. My current approach involves a ‘health check’ activity at the beginning of the workflow. If the worker is draining, this check fails, but due to session affinity, the workflow gets stuck and cannot be reassigned to another worker.

My current workaround is a complex system of per-worker task queues, which I’d like to replace.

I believe the recommended best practice is to:

1. Remove the application-level health check.
2. 2. Allow the activity to fail when the worker shuts down, which will cause a SessionFailedError.
   3. 3. Catch this error in the workflow.
      4. 4. Create a new session, which will be assigned to a healthy worker.
         5. 5. Retry the business logic.
         6. Could you confirm if this is the idiomatic and recommended approach for a self-hosted Temporal environment? Are there any other best practices or considerations for this scenario?
      5. Thank you!

[maxim]

Have you seen this?

Have you seen this?

Does Temporal Typescript support workflow session

I see. The main session feature is the ability to limit the number of such sequences of activities that can run in parallel. The session uses the following design and you can try to implement it yourself: Each process creates a separate worker with fixed parallelism (for example 1). Let’s call its task queue “process-lock”. Each process listens on a host specific task queue. For example, “host1”. To start the sequence of activities invoke “lock-process” activity at “process-lock” task queue. T…