-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NewEvents table cluttered with TimerFired events #93
Comments
I’ll need to investigate, but I think this might be expected for canceled timers. Canceling a timer doesn’t actually delete anything from the Durable store, it just tells the orchestration to not wait for it when transitioning into a completed state. I’ll be interested to know if they stay there forever or if they get deleted after their scheduled fire-time… |
Looking at the code I don't see how would these events ever be deleted ( which is confirmed by our experience so far) :
So I think that any Events that remain linked to a finished orchestration will remain un-deleted forever. Would a new Purge procedure for cleaning these orphan Events at deployment time be a good add-on? |
Our application uses timers heavily, having multiple async flows that have a deadline, and we use timers for establishing that deadline until a certain service can call back to finish an action.
We follow the best practices around working with timers and we cancel the timers if we are no longer waiting for them (if we received the callback event before the deadline).
One standard way of using timers looks something like that :
After a run of a workflow, the timers remain un-deleted in the NewEvents table, even though the instances related to them are finished (Completed, Failed, etc). Is this by design, or is it something in the way we are using timers that generates this behavior?
The text was updated successfully, but these errors were encountered: