Each activity heartbeats results in two state transitions

[dhiaayachi]

Description

At the moment, each heartbeat will incur 2 state transitions. One state transition happen when the RecordActivityHeartbeat API is called. Another state transition when the previous heartbeat timeout happens and it would create a new heartbeat timeout timer.

It seems like it might be possible to do optimize this, by creating the new heartbeat timeout timer when RecordActivityHeartbeat API is called, so when the previous heartbeat timeout timer fires, it would be a no-op, avoiding the second state transition.

[dhiaayachi]

Thank you for reporting this potential optimization! This behavior is due to how heartbeats are currently implemented. While your suggestion is a good one, the current implementation prioritizes reliability and resilience over minimizing state transitions.

Here's a workaround:

• Increase the Heartbeat Timeout: You can adjust the HeartbeatTimeout in your Temporal configuration to reduce the frequency of state transitions. By increasing the timeout, you'll decrease the number of heartbeat timeout events, leading to fewer transitions.

Let me know if you have any further questions or concerns!

[dhiaayachi]

Thank you for reporting this potential optimization!

We understand your point about the two state transitions for each heartbeat. While we don't have a specific feature to directly address this, there might be a way to work around it.

You could potentially explore a custom workflow implementation where you manage the heartbeat logic yourself, potentially eliminating the second state transition. This would involve handling the heartbeat timeout and triggering the RecordActivityHeartbeat API call manually within your workflow. Keep in mind that this approach would require careful handling of potential race conditions.

We appreciate you raising this issue. We'll consider your suggestion for future improvements.

[dhiaayachi]

Thank you for reporting this potential optimization. We appreciate your feedback!

While we don't currently have a way to avoid the second state transition as you suggested, you can work around this by setting a longer heartbeat timeout. This will reduce the frequency of state transitions.

For more information on heartbeats and timeouts, please refer to the following documentation:

• Heartbeat
• Workflow Timeouts

[dhiaayachi]

Thanks for reporting this potential optimization! We appreciate you bringing it to our attention.

Currently, Temporal's heartbeat mechanism involves two state transitions: one when RecordActivityHeartbeat is called and another when the previous heartbeat timeout expires. Your suggestion to create the new heartbeat timeout timer directly within the RecordActivityHeartbeat call is an interesting approach that could potentially reduce state transitions and optimize performance.

While this feature isn't currently implemented, we're always open to exploring potential improvements. In the meantime, we encourage you to consider these points:

• Performance impact: Measure the actual impact of these state transitions in your specific use cases. You can use Temporal's monitoring and tracing tools to analyze the performance of your workflows.
• Potential downsides: Consider if merging the timeout timer creation into the RecordActivityHeartbeat call might introduce any unintended consequences or complexity.

We value your feedback and will continue to explore ways to enhance Temporal's efficiency.