-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SYSTEST-9338 - Send events to the WS object that subscribed to it #122
Conversation
WS connection will now be taken in when event is registered. It will then be used when it is time to call the emitResponse function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! One question/comment that I don't really know the answer. Depending on your confidence with how it is now, feel free to merge. Or, if my question leads you to consider a change, just ping me again when changed.
server/src/events.mjs
Outdated
function deregisterEventListener(userId, oMsg, ws) { | ||
if (!eventListenerMap[userId]) { return; } | ||
|
||
if ( eventListenerMap[userId] && eventListenerMap[userId][oMsg.method] && eventListenerMap[userId][oMsg.method].ws === ws ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we log some kind of error if the ws values don't match? Would this be an unexpected error to somehow track down? Or... should we not compare ws values and nuke the listener record no matter what?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. That brings up a scenario I don't know if we thought of. What if a user is listening to the same method across multiple connections. Why they would do this I don't know but I guess it's possible.
Considering the fact that we're still limiting to one listen per user per method I'd say we just nuke it no matter what. But maybe we want to put in the feature for multiple listens per user per connection?
Keaton, what'd be the difficulty on that? I'm assuming we'd just be setting [ws] as an array and some logic on top to add/remove the proper one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per your request, I was able to set ws key to an array. I have renamed it to wsArr and we can now store multiple ws connections inside of the array.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 good catches/fixes/improvements
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, good catch! Didn't think of that.
Background
Mock Firebolt now supports multiple connections per user by utilizing an array/map of WS connections per userId.
This presents a problem for situations in which MF is tasked with triggering an event for a user. If a user is connected to MF with multiple connections, there is currently no way for MF to know which connection to send the requested event to.
In order to properly inject events, we must know which connection began listening to the requested event.
Implementation
MF already keeps track of which users are listening to which events. This is in order to support "sendEvent()" and "sendBroadcastEvent()" functionalities in YAML overrides as well as sending events manually using the --event CLI and its associated API. This same functionality can be extended to include which connection is listening to an event.
From there, the event functionality can be enhanced to send events to only the connections that are listening for it.
Changes Made