PATCH /api/v2/routing/queues/{id}/members 409 version bump from WS status change?

PATCH to /api/v2/routing/queues/{id}/members returns 409.

resp = session.patch(url, json={"userId": uid, "wrapUpCode": {"id": wu}, "skills": [{"id": "s1", "level": 5}], "version": ver})

Version mismatch.

I’m watching the Notification API stream.

A routing:users:queues event hits right after the GET.

Source is userStatusChange.

Agent went available.

Version bumped.

My Python script fetches the member list, constructs the update payload with wrap-up directives, then patches.

Network latency adds 200ms delay.

WS event slips in during that window.

Optimistic locking fails.

Docs claim version only updates on REST writes.

Status change shouldn’t touch the member resource version.

Yet it does.

When WS events increment the version, the atomic update logic breaks.

I’d have to subscribe to routing:users:status for every agent to track version changes.

Subscription limit is 100 per connection.

Can’t scale to 500 agents.

Does If-Match: * bypass the version check on queue members?

Also seeing 400 errors on max membership count validation when adding skills.

Need to handle both.

Cause: The userStatusChange event triggers an implicit version increment on the membership resource. Your local ver variable is stale.

Solution: You’ll need to invoke platformClient.Routing.getRoutingQueueMembersQueueIdQueueIdMembers() before the PATCH. Extract the live version integer from the response object.

{
 "userId": "uid",
 "version": <response.version>
}

It’s a classic cache miss scenario.

fresh_ver = get_queue_members(queue_id).members[0].version
payload["version"] = fresh_ver

That approach is sound. This drift corrupts the engagement metrics feeding the weekly leaderboards. You’ll need a fresh GET request before the update. The system locks the resource on status change. Updating the wrap-up code requires that latest integer.