Reminder's state manager stale value with more than one run through

[tstojecki]

Expected Behavior

Reminder that goes beyond one cycle (isn't removed after one single run through) should get an update to state eventually.

Actual Behavior

Reminder never receives an updated state if state is updated following the first run through.

Steps to Reproduce the Problem

Run example/actor demo app. Modify so that state is updated by ActorClient once the reminder had a chance to read state at least once. Notice how on subsequent runs (second, third, etc...) even though the reminder calls StateManager.GetStateAsync<> it never gets an update.

Repo showing code changes to reproduce:
https://github.com/tstojecki/dotnet-sdk/commits/reminder-stale-cache-state-bug

Release Note

RELEASE NOTE:
FIX Bug in reminder's state manager never getting an updated state.

[tstojecki]

It has to do with the internal state tracker context inside ActorStateManager.cs - appears to be some sort of per request caching mechanism? Basically the reminder is unaware of subsequent updates to the state as StateManager continues to return the value stored/cached in tracker context.

One workaround is to call StateManager.ClearCacheAsync() as that internally clears the dictionary before StateManager.GetStateAsync<>

[bitTobiasMeier]

I detected the same problem. After restarting the service the correct value will be loaded in the reminder also.

[halspang]

@tstojecki - Is this still relevant? I just tried to repro it but was not able to do so.

[halspang]

@tstojecki - Let me know if you're still experiencing any issues or can provide a repro.

[tstojecki]

@halspang the repro has been provided in the first post, please see above. I recall that this was a very basic modification of the sample from the dapr repo, meaning we didn't create anything complex to run into this.

It could be that this has been fixed by now. In fact I would be surprised if it wasn't given that it sounds like new workflow building block will rely on reminders. So if you want to run the repro and find that it works fine with the latest dapr code, feel free to close this issue.

We had to use another approach due to timing constraints.

[greensebastian]

I just encountered this problem on 1.13. This call returns different state trackers, as the actor invocation has a context id and value, whereas the reminder does not, so get's the default tracker.

dotnet-sdk/src/Dapr.Actors/Runtime/ActorStateManager.cs

Line 527 in fba9dfd

private Dictionary<string, StateMetadata> GetContextualStateTracker()