Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Don’t replace existing discontinuity event #246

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Don’t replace existing discontinuity event #246

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion textile/chat-features.textile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -191,7 +191,8 @@ As well as user-initiated operations, the room must monitor its underlying resou
*** @(CHA-RL4a3)@ @[Testable]@ If a room lifecycle operation is in progress, then a pending discontinuity event shall be recorded for this contributor - though it must not overwrite any existing discontinuity event. The @ErrorInfo@ associated with the discontinuity shall be the @reason@ for the underlying channel state change. The event will be notified to the contributor at a later point, as noted in this specification.
*** @(CHA-RL4a4)@ @[Testable]@ If a room lifecycle operation is not in progress, then a discontinuity event will immediately be emitted to the contributor. The @ErrorInfo@ associated with the discontinuity shall be the @reason@ for the underlying channel state change.
** @(CHA-RL4b)@ The state monitor must handle non-@UPDATE@ channel state events.
*** @(CHA-RL4b1)@ @[Testable]@ If a room lifecycle operation is in progress, and the new channel state is @ATTACHED@, and the @resumed@ flag is false, @and@ the particular contributor has been attached previously (i.e. a previous call to @attach()@ on the channel, per @CHA-RL1f@, has succeeded), then a pending discontinuity event will be recorded for the contributor. The error associated with this event shall be the @reason@ for the channel state change.
*** @(CHA-RL4b1)@ This clause has been replaced by "@CHA-RL4b11@":#CHA-RL4b11.
*** @(CHA-RL4b11)@ @[Testable]@ If a room lifecycle operation is in progress, and the new channel state is @ATTACHED@, and the @resumed@ flag is false, @and@ the particular contributor has been attached previously (i.e. a previous call to @attach()@ on the channel, per @CHA-RL1f@, has succeeded), then a pending discontinuity event will be recorded for the contributor - though it must not overwrite any existing discontinuity event. The error associated with this event shall be the @reason@ for the channel state change.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
*** @(CHA-RL4b11)@ @[Testable]@ If a room lifecycle operation is in progress, and the new channel state is @ATTACHED@, and the @resumed@ flag is false, @and@ the particular contributor has been attached previously (i.e. a previous call to @attach()@ on the channel, per @CHA-RL1f@, has succeeded), then a pending discontinuity event will be recorded for the contributor - though it must not overwrite any existing discontinuity event. The error associated with this event shall be the @reason@ for the channel state change.
*** @(CHA-RL4b11)@ @[Testable]@ If a room lifecycle operation is in progress, and the new channel state is @ATTACHED@, and the @resumed@ flag is false, @and@ the particular contributor has been attached previously (i.e. a previous call to @attach()@ on the channel, per @CHA-RL1f@, has succeeded), then a pending discontinuity event will be queued for the given contributor. The error associated with this event shall be the @reason@ for the channel state change.

This also makes implementation explicit about maintaining a queue of discontinuity events

Currently, chat-js room lifecycle maintain only latest discontinuity event. Was there a reason for it @AndyTWF 🤔

Also, I am not sure whether we should maintain queue of discontinuity events, since aim is to let user know that there was a discontinuity only once, and in the case of messages feature, they might like to fetch missed messages.
For other features, it might not make much sense.
i.e. customers, won't care much about discontinuity in the first place 💁‍♂️

  1. Presence - Automatically synchronizes members on the channel after channel ATTACH, so subscribers will automatically get latest members after re-attach caused by reconnection
  2. Occupancy - It's just a stat about available members, after reconnection, we will automatically get latest data, so subscribers will automatically get latest members after re-attach caused by reconnection
  3. Typings - This is more like an ephermal feature, customers would hardly care if they missed typing events. After reconnection, they can always receive new typing events from senders
  4. Reactions - This is same as typing feature, both are ephermal in nature.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also strongly believe we should avoid exposing too much internal information unless absolutely necessary. Keeping things simple will help customers get the SDK up and running with minimal setup, without introducing unnecessary complexities that could make it harder to understand.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intention always was that there would be at most one discontinuity event for any given period of discontinuity (i.e. period of the room status not being ATTACHED). The reason for this was so that we don't spam users: ultimately, they need to know that there was a discontinuity (and ideally the reason for it), they don't need to know a play-by-play of all the discontinuities that may occur as part of a retry loop.

So the spec should reflect the idea of "the first discontinuity observed".

Whilst I agree that other features are not as important in terms of discontinuity, we wanted to add the feature so that it was consistent across chat features.

Copy link
Collaborator

@sacOO7 sacOO7 Nov 28, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean "the first discontinuity observed" or "the latest discontinuity observed"?
Like current chat-js impl. stores "the latest discontinuity observed", this also means we don't need a queue?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So CHA-RL4a3 would need rephrasing instead of CHA-RL4b1

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like current chat-js impl. stores "the latest discontinuity observed", this also means we don't need a queue?

chat-js stored the first one observed, whenever a discontinuity trigger comes up it checks if ones already stored first

Copy link
Collaborator

@sacOO7 sacOO7 Nov 28, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw, I would like to highlight type of discontinuities

  1. When connection goes suspended and attaches again, ATTACHED msg will have resumed set to false -> RTL2f
  2. When connection is connected but your token/app has restricted msg/sec rate, so it can receive duplicate ATTACHED with RESUME false and error - msg/sec rate exceeded -> RTL12

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The second point seems to be related to #239.
So, does it really make sense to only store first discontinuity observed? Maybe they wouldn't care much about error caused by RTL2f, but if app has some restrictions over publish/subscribe rate, then they would like to know and fix it in the long term.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like the criteria can be, discontinuity error can be overridden if the previous+current state is ATTACHED and resumed is false over the same connection.

*** @(CHA-RL4b2)@ This specification point has been removed.
*** @(CHA-RL4b3)@ This specification point has been removed.
*** @(CHA-RL4b4)@ This specification point has been removed.
Expand Down
Loading