Notification API WebSocket: Handling subscription scope drift in multi-tenant Terraform deployments

Is it possible to maintain a stable WebSocket connection for conversation events when the underlying user context changes dynamically via Terraform?

I am managing a multi-org Genesys Cloud deployment using Terraform modules. The setup provisions users and their associated notification subscriptions programmatically. When I update the user’s team or routing profile via terraform apply, the active WebSocket session for that user seems to lose its event scope. The connection doesn’t drop, but the event stream stops delivering conversation:created or conversation:updated events for new interactions assigned to that user.

I’m using the standard Notification API WebSocket endpoint:

wss://{{host}}/api/v2/notifications?access_token={{token}}

My client implementation subscribes to the conversation topic with a specific user ID filter. Here is the subscription payload I send upon connection establishment:

{
 "type": "subscribe",
 "data": {
 "topic": "conversation",
 "filters": {
 "userId": "{{user_id_from_tf_state}}",
 "eventTypes": ["created", "updated", "deleted"]
 }
 }
}

After a Terraform state update that modifies the user’s attributes, I have to manually disconnect and reconnect the WebSocket to restore the event flow. This is unacceptable for a production-scale orchestration layer where I manage thousands of concurrent sessions via a Node.js worker pool.

I suspect the server-side subscription cache is tied to the user’s initial context hash. Is there a way to force a subscription refresh or re-authenticate the scope without tearing down the TCP connection? Or is there a specific header or message type I’m missing to update the filter dynamically?

I’ve tried sending an empty subscribe message with updated filters, but the server ignores it. The only reliable fix currently is a full reconnect, which causes a 2-3 second gap in event processing. This breaks our real-time analytics pipeline.

Any insights on how to handle this lifecycle event in the Notification API? I need a code-level solution, not a workaround involving polling.