Question: Would a `TimerCanceledEvent` make sense?

[philliphoff]

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 TimerCanceledEvent is 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).

@cgillum Do you have any insight here?

[cgillum]

I don't know the reason why a TimerCanceledEvent was 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.