Web Messaging SDK 409 Conflict on closed engagement creation loop

NICE CXone API & Integrations
1

Problem
The @genesys/web-messaging-sdk v2.9.1 throws a silent failure on the authenticated messenger flow when the Platform API returns a 409 on engagement creation. The widget mounts fine, but the interaction queue never populates, doing jack all. This broke our prod queue for 4 hours yesterday. The logs show the SDK is retrying the POST to /api/v2/messaging/engagements with the same engagementId that the backend already marked as closed. The edge config has a batch size of 50, but this is a single user session, so that’s irrelevant. The network tab catches the response.

Code

const client = new GenesysCloudWebMessaging({
 organizationId: 'org-123',
 authenticated: true,
 tokenProvider: async () => await fetchToken()
});

client.on('engagement.created', (e) => {
 console.log('Created:', e.id);
});

Error
The browser console stays quiet, but the network tab catches this response from the Platform API:

{
 "code": "Conflict",
 "status": 409,
 "message": "Engagement ID eng-998877 already exists in state closed. Shard 4 routing error.",
 "details": "Duplicate key violation on engagement_id_index"
}

The SDK doesn’t handle this 409 gracefully. It just loops the retry mechanism without resetting the ID generator. We’ve got a batch size of 50 configured in the edge config, but this is a single user session.

Question
Should the widget generate a new UUID on 409, or is the Platform API supposed to return a 410 Gone for closed engagements? The docs mention idempotency keys but nothing about closed state collisions.