Repository navigation
Question: Would a TimerCanceledEvent make sense? #480
Description
Activity
I don't know the reason why a
TimerCanceledEventwas not included in the original versions of DTFx. Perhaps because it wasn't technically required and/or it wasn't easy to actually cancel a timer which is represented as a queue message.I think it makes sense to have this event. It will allow backends to proactively remove timer resources (if possible) and will improve diagnostics, whether that's manual history inspection or DTS dashboard visualization.
One thing we have to be careful about is introducing a breaking change to existing orchestrations.
Reacted by Phillip Hoff and Willem KoeterIssue Triage
Classification:
triage/requires-redesignReasoning:
Per maintainer Chris Gillum (@cgillum)'s comment, aTimerCanceledEventwould be a fundamental new event type affecting all platforms. While the concept makes sense for diagnostics and backend resource cleanup, it requires careful cross-platform design consideration to avoid breaking changes to existing orchestrations. This needs architectural discussion about event format, backward compatibility, and multi-platform implementation.Automated fix candidate: No
- Requires cross-platform design discussion
- Would introduce a new event type affecting the orchestration history
- Risk of breaking changes to existing orchestrations as noted by maintainer
At least for .NET, timers must be canceled before an orchestration can enter the completed state. However, this is purely a worker-based concept, as no corresponding
TimerCanceledEventis logged when that occurs. Why is that? A consequence is that a timer will always appear "active" in a timeline unless/until it either fires or the orchestration completes, even when the orchestration implementation "cancels" it.Would it make sense to log a
TimerCanceledEvent? Is this a concern only in .NET or is the behavior the same across platforms? I imagine that every platform would need changes to accommodate a fundamental new event, even if there was no need to change the behavior of the runtimes in response to it (i.e. if the intent was solely for timeline generation purposes).Chris Gillum (@cgillum) Do you have any insight here?