The docs make it clear that StartToClose timeout should be set slightly longer than the longest possible execution time for a given Activity, which makes perfect sense. But what happens if you underestimate that value, and your Activity execution time exceeds the timeout, but hasn’t actually crashed? I assume you end up with a duplicate Activity execution, but what impact does that actually have on the Workflow execution?
Similarly If you’re heartbeating in the Activity, will you get an exception if you try to heartbeat after the Heartbeat/StartToClose timeout has expired?
what impact does that actually have on the Workflow execution?
Yes, StartToClose timeout is max time you define for a single activity invocation. If your activity executes for longer than this timeout it will be retried according to the set retry policy. Note that when the activity execution times out due to StartToClose it can still complete, but its results wont be recorded in history (when it tries to record its completion server would return a not found service error: NOT_FOUND: invalid activityID or activity already timed out or invoking workflow is completed).
From the workflow execution perspective when retries of this activity are exhausted you would need to handle ActivityFailure which should include TimeoutFailure as its cause (and would include “activity StartToClose timeout” as its message).
If you’re heartbeating in the Activity, will you get an exception if you try to heartbeat after the Heartbeat/StartToClose timeout has expired?
Yes, if your activity execution reaches StartToClose timeout or does not heartbeat within the set HeartbeatTimeout, its next heartbeat will fail (with for example in Java throw io.temporal.client.ActivityNotExistsException or in Go would cancel context with error context.Canceled).