Looking for advice on handling 409 Conflict errors when automating bulk schedule updates via the PATCH /api/v2/wfm/scheduling/schedules/{scheduleId} endpoint. We are running a Python script (using genesyscloud-python-sdk v132.0.0) to process agent-initiated shift swaps and time-off requests for our Chicago-based support center (America/Chicago timezone). The script fetches the current schedule version, applies the requested changes locally, and attempts to publish the updated schedule. While individual updates work fine, processing a batch of 50+ concurrent shift swaps during peak planning hours triggers sporadic 409 Conflict responses with the message: The provided schedule version does not match the current version in the system. We implemented a basic retry mechanism with exponential backoff, but the conflicts persist because the schedule version changes rapidly due to other agents making self-service adjustments in the UI simultaneously. The error payload includes currentVersion: 145 and providedVersion: 144. We are trying to determine if there is a best practice for optimistic locking in this context or if we should be using a different approach, such as fetching the latest version immediately before each PATCH request within the same loop iteration. Currently, we are fetching the schedule once at the start of the batch process, which clearly becomes stale. Switching to a per-agent fetch adds significant latency to the script execution. Has anyone successfully implemented a robust retry or merge strategy for high-throughput schedule modifications without causing data integrity issues or excessive API call volumes? We want to ensure that legitimate shift swaps are not rejected simply due to version mismatch timing.