Trying to understand why weekly schedule publishing is failing with a 409 Conflict error on our BYOC Edge deployment in America/Chicago.
Shift swaps are approved in the UI, but the API call to /v2/wfm/schedules rejects the payload. Is there a known latency issue with conflict resolution on Edge?
check if your edge time is actually synced to ntp. i’ve seen this 409 pop up when the local clock drifts more than 2 seconds from the gc core during the publish window. fix the time source first.
Cause: the 409 is likely not a time sync issue but a data conflict in the schedule payload. when pushing to BYOC edges, the API sometimes rejects updates if the local cache hasn’t synced with the core yet, or if there’s a duplicate shift ID in the request.
Solution: try clearing the local schedule cache on the edge node before re-publishing. also, check the shift swap status in the UI-sometimes the API sees a pending state while the UI shows approved. here’s a quick curl to check the edge health:
curl -X GET https://{your-edge}/v2/health | jq .status
if the status is ‘syncing’, wait it out. if it’s ‘healthy’, look at the shift IDs in your payload. ensure no two shifts have the same ID. i’ve seen this happen when manual overrides clash with auto-scheduling rules. check the audit log for the exact conflict reason. it usually lists the clashing resource ID.
nah, it’s probably not the edge clock. we had this exact headache last week with our byoc setup in melbourne. the 409 was actually because the api was hitting the core before the local cache finished syncing. the edge was saying “approved” but the core still saw it as “pending” for a split second.
we fixed it by adding a small delay script before the publish call. nothing fancy, just a wait. also make sure you aren’t sending duplicate shift ids. that trips up the validator hard.
# simple wait before publish
sleep 5
curl -X POST /v2/wfm/schedules/publish \
-H "Authorization: Bearer $TOKEN"
if you are in apac or using the .au instance, the latency spikes make this worse. check the acma logs too, sometimes they block the sync if there’s a compliance flag. try clearing the edge cache first though. that usually clears the duplicate id error.
look at the retry-after header. the 409 isn’t just a sync lag, it’s a hard conflict on the entity version. if you’re ignoring that header, you’re fighting the API.
also, check your shift IDs. if the edge cache hasn’t fully replicated the swap approval to the core before you hit /v2/wfm/schedules, the validator sees a mismatch. don’t just sleep() blindly. parse the response.
response = requests.put(url, json=payload)
if response.status_code == 409:
# check if it's a version conflict or just latency
retry = int(response.headers.get('retry-after', 1))
time.sleep(retry)
# retry with the latest etag if you have it
the real fix is handling the 429 properly too. don’t just backoff blindly. parse the retry-after header. if the edge is in America/Chicago and your core is elsewhere, the clock drift might be masking a deeper replication lag. fix the time source, but more importantly, implement proper exponential backoff with jitter. the API is telling you to wait. listen to it.