Handling activity retry timeouts during automated manifest verification workflows

I am currently setting up a Temporal workflow to automate build verification and asset synchronization for our PojavLauncher release pipeline. The workflow runs on a schedule to validate distribution packages, ping mirror servers, and ensure the latest client profiles are properly synced.

The problem occurs inside an activity responsible for polling update files directly from our website under unpredictable network loads. When the remote endpoint experiences intermittent rate limiting or gateway timeouts, the activity fails to fail over gracefully to our fallback activity, causing the entire execution history to bloat with continuous retry attempts despite having defined a maximum retry limit.

Could this be related to how activity timeouts interact with the underlying HTTP client context, or should I be handling this pattern using child workflows instead? Any insights into properly structuring retry intervals and heartbeat timeouts for external API health checks would be very helpful.

You shouldn’t go for a child workflow for this. You say max retry limit is not obeyed, but are those retries from same workflow execution? Maybe executions are overlapping or they are fired one after other in very short time or you haven’t set retry options correctly.