chat: room attachment requirements

[AndyTWF]

Adding room attachment requirements to Typing and Presence.leave

[sacOO7]

PR is upgrade of missing spec in #232

[sacOO7]

Can we also update
@(CHA-PR10e)@ @[Testable]@ If the room status is @Attached@, then the @update@ call will invoke the underlying @presence.enter()@ call.
to
@(CHA-PR10e)@ @[Testable]@ If the room status is @Attached@, then the @update@ call will invoke the underlying @presence.update()@ call.

[sacOO7]

While I agree that we need to ensure the room state is ATTACHED before performing any room operations, we currently face a lot of specification duplication for user-triggered room actions.

In Kotlin, we've defined the ensureAttached method as part of the DefaultRoom class, which returns a promise (in JavaScript) or a callback in other languages.

DefaultRoom.ensureAttached() method:

• This method is simply called before executing any user-triggered real-time operations, at multiple places.
• It's easy to test and avoid lot of code duplication/ simplifies spec understanding.

[sacOO7]

Perhaps we can streamline the specification so that we don't need to define multiple spec points (currently 3) for basic user-triggered real-time room operations. This will help in future specifications as well.

[AndyTWF]

While I agree that we need to ensure the room state is ATTACHED before performing any room operations, we currently face a lot of specification duplication for user-triggered room actions.

In Kotlin, we've defined the ensureAttached method as part of the DefaultRoom class, which returns a promise (in JavaScript) or a callback in other languages.

DefaultRoom.ensureAttached() method:

• This method is simply called before executing any user-triggered real-time operations, at multiple places.
• It's easy to test and avoid lot of code duplication/ simplifies spec understanding.

I'm cautious to define exact implementation details (e.g. specific method names) in the spec, so as to give latitude to different SDKs to be idiomatic to their ecosystems.

But in a future PR I'll look at consolidating the points - perhaps a GA item

[sacOO7]

Suggested change

	*** @(CHA-T4a2)@ @[Testable]@ When a typing session is started per @CHA-T4a1@, a timeout is set according to the @CHA-T3@ timeout interval. When this timeout expires, the typing session is automatically ended by leaving presence.
	*** @(CHA-T4a2)@ @[Testable]@ When a typing session is started per @CHA-T4a1@, a timeout is set according to the @CHA-T3@ timeout interval. When this timeout expires, the typing session automatically ends by leaving presence as per @CHA-T5c@.

[sacOO7]

I think we should implement an internal retry mechanism if the implicit presence.leave fails due to a timeout.
This can become important because we won't be notifying the user about errors produced by leave event due to implicit typing timeout.
Though, we do have an explicit stop method that takes notifies user whether typing stopped or not, most of the times user will rely on start method to produce stop event on timeout

[AndyTWF]

Yes - this is a known bug that we intend to fix at a later date, I would prefer not to spec for it until we know what that is

[sacOO7]

if implicit leave event fails due to typing timeout, receivers will see eternal typing in progress : (
Unless, user disconnects explicitly. Also, on reconnection, presence members are entered again.

[AndyTWF]

Yes - it's a known bug tracked in a Chat JIRA ticket. Once someone fixes it in a satisfactory way (in any of the SDKs), we'll update the spec - I just don't want to write a spec point for it until we have a tried and tested fix :)

[sacOO7]

If we are tracking it somewhere then good 👍

• Otherwise you might like to create separate github issue for this WDYT
• I think use-case is pretty clear => if leave fails on timeout then we have eternal typing
  event on receiver side 🤷‍♂️

[sacOO7]

Just an idea,

• All implicit ops that don't notify user about the error are retried for max_retries = 3 and then added to the internal queue of implicit failed operations.
• All those operations will be performed again once the connection goes connected.

[sacOO7]

Seems as per RTP16b, presence events will be queued at channel level when channel in Initialized or Attaching state.

[sacOO7]

For other states, operation will result in error as per RTP16c

[sacOO7]

You might like to add those points to JIRA ticket, I will approve the PR for now, to unblock the spec

[sacOO7]

LGTM.
You can add some points from conversation into internal JIRA ticket