Batch client updates #1448
Batch client updates #1448
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
| @@ -678,7 +678,7 @@ function broadcastResult(_target: any, _propertyKey: string, descriptor: Propert | |||
| // we do the comparison by explicitly for each property | |||
| // to apply custom logic for different datasets | |||
|
|
|||
| const shouldForceTimerUpdate = getForceUpdate(RuntimeService.previousTimerUpdate, state.clock); | |||
| const shouldForceTimerUpdate = getForceUpdate(RuntimeService.previousTimerUpdate, state.clock); //FIXME: pause causess an avlache of update if timer is negative | |||
alex-Arc
force-pushed
the
patch-client
branch
from
528a6f7 to
c3be94c
Compare
alex-Arc
force-pushed
the
patch-client
branch
from
7ad90e3 to
bd9e655
Compare
| const stringifiedPatch = JSON.stringify({ type: 'ontime-patch', payload: patch }); | ||
|
|
||
| // for each client that have subscribed to the patch method send the patch object | ||
| this.patchClients.forEach((ws) => { |
There was a problem hiding this comment.
do you think this is necessary?
I understand the motivation behind it, but I wonder if trying to keep backwards compatibility makes our code harder and more bug prone
I am ok with this as long as we are not trading the above for the compatibility
There was a problem hiding this comment.
We would have to do a breaking version change right?
I would love to keep it simple, but I have no idea what things that are dependent one us?
There was a problem hiding this comment.
what if we continue sending the messages in serial?
the logic of the store should accumulate changes in the same event loop iteration, maybe the small difference in milliseconds on the message being received and parsed will not be visible?
There was a problem hiding this comment.
hmm yeah it's worth a try
The goal here is to stabilize runtimestate so that calculations that combine data from runtime or timer and clock don't have incorrect data in the time between receiving the two datasets. Without affecting the mitigations we tried to put in place for #940
this is attempted to be done by allowing ws client to subscribe to either a key model or a patch model when connectionall data written to
eventStore.setwill be batch with usingsetImmediateso it should be sent next eventloop tick but all the data set will be sent together