Question: Would a `TimerCanceledEvent` make sense?

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?

Start with the linked .NET timer documentation and the issue's observation that cancellation is worker-based and emits no TimerCanceledEvent. Check whether other platforms have the same behavior and assess the cross-platform implications of adding a fundamental event. Done means a maintainer decision on whether the event is needed and what runtime or timeline changes would be required.