PATCH users/{userId}/queues response with 200 OK joined still on original value

[ast1]

When PATCH https://api.mypurecloud.de/api/v2/users/{userId}/queues with queue ids such as
[
{
"id": "queueid_1",
"joined": false,
"name": "nameofqueue1",
"selfUri": "/api/v2/routing/queues/queueid_1"
},
{
"id": "queueid_2",
"joined": false,
"name": "nameofqueue2",
"selfUri": "/api/v2/routing/queues/queueid_2"
}
]

we noticed that the 200 OK would contain the joined parameter still set to true as it was before the PATCH.

{
"entities": [
{
"id": "queueid_1",
"name": "nameofqueue1",
"joined": true,
"selfUri": "/api/v2/routing/queues/queueid_1"
},
{
"id": "queueid_2",
"name": "nameofqueue2",
"joined": true,
"selfUri": "/api/v2/routing/queues/queueid_2"
}
],
"pageSize": 2,
"pageNumber": 1,
"total": 2,
"lastUri": "/api/v2/users/{userid}/queues?pageSize=2&pageNumber=1",
"firstUri": "/api/v2/users/{userid}/queues?pageSize=2&pageNumber=1",
"selfUri": "/api/v2/users/{userid}/queues?pageSize=2&pageNumber=1",
"pageCount": 1
}

Similar result via Genesys Cloud UI using the dev console and using the API explorer.

We have a partner that developed some logic on top of the joined parameter from the response and due to their understanding of the 200 OK response, they are setting misleading queues active to agents in the UI.

[tim.smith]

Please open a case with Genesys Cloud Care to report the issue with the returned data. We cannot investigate org-specific data via the forum.

There's a chance that this endpoint uses an eventual consistency pattern, but it's not documented that way and returns a 200 indicating success, not a 202 that would indicate that additional processing may still be happening.

[ast1]

Thanks, Tim. I documented the case with Genesys. I will update the post here with generic information based on the investigation.