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?
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).@cgillum Do you have any insight here?