I have an application that's monitoring > 1000 subscription topics. Because a notification channel caps out @ 1000, I have a collection of NotificationHandler objects, each of which handles up to 999 subscription topics.
Because I want them all to be handled by the same code, each NotificationHandler's NotificationReceived event fires to the same method matching the NotificationReceivedHandler delegate.
That delegate, however, only provides the INotificationData, and not the actual INotificationHandler (sender) object that fired the event, which prevents me from tracking which messages came in on which channels.
This is particularly important for handling a v2.system.socket_closing message.
To start with, am I using this correctly or is there a better way to handle > 1000 subscription topics
If so, Can I request a change to the delegate to provide the INotificationHandler sender as an additional argument?
since it seems like you're doing some sort of bulk monitoring, you might be better served by the EventBridge integration that has less scale limitations as it's intended for bulk monitoring. WebSocket notifications are intended for single-user client apps and don't necessarily scale in ways you'd desire for large-scale use cases. https://developer.genesys.cloud/notificationsalerts/notifications/event-bridge
I'll pass this request on to the SDK team for consideration, but making a breaking change to the event handler's signature probably isn't something we want to do given how established the SDK is.
Your issue is caused by your app attaching the same event handler to multiple channels, which causes it lose context because it conflates events from multiple sources. A better pattern would be to wrap the NotificationHandler in your own class that can handle the event from a single channel and raise its own event that contains the WebSocket event as well as any additional contextual data you want based on the channel or anything else.
Unfortunately, for various reasons, AWS is off the table for this app, but that's great to know for future developments, appreciate the info.
I had already considered wrapping the NotificationHandler, but avoided it due to how many native usages of it we already have but I guess that seems like the right answer here.
We're subscribing to v2.users.{userId}.routingStatus for a select subset of users. I don't think we can wildcard that for a combined list of ~3000 users.
You could also add the NotificationHandler.cs class to your project, modify it the way you want, and just update the namespaces of your usages to point to your version of the class. Of course you won't automatically get any updates we make to the class in the future, but it's very unlikely to change. It's probably a toss-up on which is more effort, but I wanted to mention it since we open source the SDKs so you can do what you want with their code.
For anyone who finds this thread later -- I ended up doing both. I created a wrapper around NotificationHandler which can refresh the channels every 23h40m as well as keeps tabs on the heartbeat metadata messages in case they stop.
In addition, i also copied NotificationHandler.cs (and INotificationHandler.cs) to my project so that I could implement RemoveSubscriptions. Because there was no bulk remove method and removing in a loop jeopardized our API rate limit.