Configure Temporal Activity retry policy, the four activity timeouts, heartbeating, and cooperative cancellation

Documented steps

1. Set at least one of the two required timeouts when invoking an Activity. `schedule_to_close_timeout` / `scheduleToCloseTimeout` caps the entire Activity Execution including all retries (default: unlimited). `start_to_close_timeout` / `startToCloseTimeout` caps a single attempt and, if unset, defaults to the Schedule-To-Close value. The docs recommend always setting Start-To-Close explicitly, e.g. `start_to_close_timeout=timedelta(seconds=10)`.
2. Optionally set `schedule_to_start_timeout` / `scheduleToStartTimeout` (default: unlimited) to bound how long a task may sit in the task queue before a worker picks it up. This is useful for detecting worker fleet capacity problems.
3. Build a retry policy — Python `temporalio.common.RetryPolicy`, TypeScript the `RetryPolicy` interface from `@temporalio/common` — and pass it as `retry_policy=` / `retry:` on the activity call. Documented defaults: initial interval 1 second, backoff coefficient 2.0 (must be >= 1), maximum interval 100x the initial interval, maximum attempts unlimited, and an empty non-retryable error type list.
4. For long-running Activities set `heartbeat_timeout` / `heartbeatTimeout` — the maximum allowed gap between heartbeats. If exceeded, the Activity Task fails and is retried under the retry policy.
5. Inside the Activity implementation call `activity.heartbeat(details)` periodically to report liveness and progress. Heartbeating is also what makes the Activity able to receive cancellation.
6. Understand heartbeat throttling: the worker sends at most one heartbeat per throttle interval, computed as the smaller of 80% of `heartbeatTimeout` (or `defaultHeartbeatThrottleInterval`, 30 seconds, when no heartbeat timeout is set) and `maxHeartbeatThrottleInterval`, 60 seconds. The final heartbeat before a failure bypasses throttling.
7. To make an Activity cancellable from the workflow, the docs are explicit: the Activity must send heartbeats AND have a Heartbeat Timeout set. Without both, the workflow can request cancellation but the Activity process never learns of it until a timeout fires or it completes.
8. Handle cancellation in the Activity body: wrap the heartbeating work in try/except, catch `asyncio.CancelledError` (Python), run cleanup, then re-raise. Re-raising is required for the Activity to be reported as canceled rather than swallowed.
9. From the workflow, cancel a running Activity via the activity handle's `.cancel()`. Delivery happens at the Activity's next heartbeat opportunity, not instantly. Local Activities can be canceled without heartbeats.
10. For in-flight Activity behavior during worker shutdown, consult the worker shutdown documentation on how the worker drains and cancels outstanding Activity tasks.
11. Reference docs: https://docs.temporal.io/activity-execution | https://docs.temporal.io/encyclopedia/detecting-activity-failures | https://docs.temporal.io/develop/python/failure-detection | https://docs.temporal.io/develop/typescript/failure-detection