improvement(client-presence): Consistent event ordering and state results

[WillieHabi]

Description

For consistent data reads, events from value manager updates should be placed in a queue to be processed directly after the incoming signal is processed. Then any data explorations a customer may trigger from event will get current values.

This PR makes every workspace return a list of "post update actions" that must be executed after every updated is processed from the incoming signal. This makes sure that if a client gets receives event from one update, all other updates within the same datastore update message will be consistently reflected.

Tests:

ValueManager eventing
  - is consistent with attendee + latest value manager updates
  - is consistent with attendee + latest map value manager updates
  - is consistent with attendee + notifications updates
  - is consistent with attendee + latest value manager + latest map value manager updates

Fixes AB#29542

Copilot reviewed 5 out of 8 changed files in this pull request and generated no comments.

Files not reviewed (3)

• packages/framework/presence/src/internalTypes.ts: Evaluated as low risk
• packages/framework/presence/src/latestMapValueManager.ts: Evaluated as low risk
• packages/framework/presence/src/latestValueManager.ts: Evaluated as low risk

Comments suppressed due to low confidence (1)

packages/framework/presence/src/notificationsManager.ts:254

• The return type of the update method should be consistent. If there are no listeners, it should return an empty array. This ensures that the caller can always expect an array, regardless of whether there are listeners or not.

return [];

[jason-ha]

Doesn't seem to be returning any post update actions. Missing test coverage?

[jason-ha]

I feel like maybe this was covered in a past review, but there isn't a comment.
Why is joiningAttendees a set?
If it doesn't need to be a set, then I recommend populating events instead of building set.
If set is needed, please comment. Then I recommend moving array declaration to later where it is built. (Also use PostUpdateAction type?)

[WillieHabi]

A set isn't needed, we should just populate events here

[jason-ha]

Not just state - order consistency should apply to notifications too. And beyond that the ordering matters for workspaceActivated (those need to happen early and let local registrations happen immediately, so they get updates especially for Notifications)
Also add a vertical space here.

[jason-ha]

Looks like the test cases are only checking piece-wise consistency. During any event all of the states should be consistent with the final state.

[WillieHabi]

During any event all of the states should be consistent with the final state.

I think that's what is being tested here(?) Prior to update we set up all event listeners and each listener makes sure all other updates are reflected. If an event triggers before all updates are reflected the test will fail.

[WillieHabi]

Maybe if there's an example scenario not covered I'd understand better

[jason-ha]

How about this? Revert all of your implementation changes and see what parts of tests pass/fail.
You have changed things so you will see more failure than when I first commented.
But you also have too much tested at once such that a failure isn't pointing to one thing.
And I think that last test passes even if no events are fired.

[jason-ha]

Here is a little more detail on how to see what is going on. Revert implementation. Run tests. For line that fails, remove it and repeat. In the end there will still be new verifications that are passing without any impl changes.

[WillieHabi]

Tried a new implementation where we wait for the first event to fire and immediately check all state after (then finish by making sure all events fire). The first event's update will be reflected and pass regardless of new impl, but we still have to test this I'd assume.

Would it be better to have tests separated into "is consistent on {latestValue | attendee| latestMap | notification} update" where we wait for a one specific update and then check state after? One of these tests would still pass since it would be the first event.