Try to assert that audience is superset of quorum

[vladsud]

We run into a case where there was a client in quorum that never left (i.e. there was no leave op for this client even though there was no such client connected via websocket). The issue is fixed on server side, but it would be great to have client side telemetry to find these cases.

It was easy to spot it - that same client was missing from Audience.
At the same it was hard to say what's wrong, as summaries were not going at all, but presence well was not showing any users, so it felt like client summarizing logic was broken. Overall, it was totally broken from user POV (summaries not going).

Note that Audience is superset of quorum, but due to async nature of populating audience, we can't easily assert that. But if we can track users over long period of time, then we should be able to assert users that are not showing up in audience for very long time.
In addition, it might be great to merge these two data structures in terms of presentation layer to consumers. It's very confusing for people to have two, have async population, have self missing from audience on raising connected event, etc.

[markfields]

I'll add this back to Reliability I guess. This issue needs a lot more clarity... but it sounds like the point is to add better detection of an invalid state to fail faster, which fits in the Reliability Workstream.

[markfields]

@vladsud Can we focus this one on the assert you mention in the title, and track the bigger design question around quorum/audience in a separate place? Trying to make sure stuff in the Reliability Workstream is crystal clear.

[vladsud]

I do not think it will be possible, simply because Audience & Quorum represent different points in time.
So partially that's by design. However this design is super confusing to consumers and they do not have good way of dealing with it today, especially with async nature to Audience relative to other things (like connected events, population of self).
So I think we need to clearly articulate where we want to get to in long run, and then figure out what we should do in short terms.

[markfields]

Ok, yes that clear articulation is what I'm asking for, and if we don't have it then I'm marking this as design-required and removing the "bug" label.

[ghost]

This issue has been automatically marked as stale because it has had no activity for 180 days. It will be closed if no further activity occurs within 8 days of this comment. Thank you for your contributions to Fluid Framework!