[Workflow] Workflow actor state should be saved with a TTL of -1

[cgillum]

In what area(s)?

/area runtime

What version of Dapr?

1.11

Expected Behavior

The Dapr Workflow engine should save actor state with a TTL of -1 to ensure any global TTL configuration doesn't cause workflow state to be lost, even if the actor state store has a default TTL specified.

Note that there is some discussion about whether or not TTLs should ever be configured for actor state stores here: #3658. Either way, the internal workflow actors should defend against this.

Actual Behavior

Workflow actor state is saved without specifying any TTL, making it vulnerable to state store configurations with TTLs configured.

Steps to Reproduce the Problem

1. Configure an actor state store with a short TTL
2. Run a long-running workflow that will exceed the above TTL

Release Note

RELEASE NOTE: FIX Prevent actor TTL configuration from disrupting workflows

[ItalyPaleAle]

The default behavior of Dapr components is to not set a TTL if the TTL is unset.

[cgillum]

@clintsinger or @olitomlinson would you be able to comment further on this issue? This was originally discussed on Discord, and my understanding was that there could be a default/global TTL configuration placed on state stores. I didn't actually do the work to verify this, though.

[olitomlinson]

@cgillum

I think the problem here is that TTLs can be set completely external to Dapr, depending on the chosen state technology

I.e. in CosmosDb, you can set a default TTL which applies to any document in the container. So, as @berndverst suggests, setting ttl to -1 will override any default TTL behaviours applied outside of Dapr.

[ItalyPaleAle]

@olitomlinson yes, in the case of Cosmos DB you can set a default TTL and in that case you must set -1 to override it. I do not believe any other database we support has the same behavior.

IMHO this is not a Workflows issue but rather we just need to document that people shouldn't enable TTLs with a default value in Cosmos DB.

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[dapr-bot]

This issue has been automatically closed because it has not had activity in the last 67 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.

[rabollin]

/keep-alive

[dapr-bot]

👋 @rabollin, my apologies but I can't perform this action for you because your username is not in the allowlist in the file .github/scripts/dapr_bot.js.

[cgillum]

Marking as P2 since this may be a corner case. There's also discussion of excluding Azure Cosmos DB from the list of supported workflow state stores, and it seems that may be the only state store potentially impacted.