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
Pass WS object to registerEventListener and deregisterEventListener functions inside of messageHandler.mjs.
Modify registerEventListener, deregisterEventListener, & emitResponse functions inside of events.mjs.
registerEventHandler now takes in a ws object and it is added in the eventListenerMap.
When it is time to call emitResponse, the WS object is retrieved from the eventListenerMap and used to send the response.
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