Skip to content

Implicit attach on channel.objects.getRoot() call #472

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

Open
lawrence-forooghian wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Implicit attach on channel.objects.getRoot() call #472

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e157409
Implicit attach on `channel.objects.getRoot()` call
VeskeR May 12, 2026
2c9b91b
Updated spec for implicit attach as per review comments
sacOO7 May 19, 2026
582f2e2
Addressed review feedback, added separate spec point for `ensure-acti…
sacOO7 May 20, 2026
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
8 changes: 7 additions & 1 deletion specifications/features.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -820,6 +820,11 @@ The threading and/or asynchronous model for each realtime library will vary by l
- `(RTL32e)` Any params provided in the third argument must be sent in the `TR4q` `ProtocolMessage.params` field, as a `Dict<String, String>` (that is, with the values of the provided dict stringified per `RTC1f`)
- `(RTL32c)` The SDK must not mutate the user-supplied `Message` object.
- `(RTL32d)` On success, returns an `UpdateDeleteResult` object containing the version serial of the published update, obtained from the first element of the `serials` array of the [TR4s](#TR4s) `res` field of the `ACK`. Indicates an error if the operation was not successful.
- `(RTL33)` *Ensure-active-channel* internal procedure. When invoked, the SDK MUST inspect the current state of the `RealtimeChannel` (see [RTL2](#RTL2)) and proceed as follows:
- `(RTL33a)` If the channel is in the `ATTACHED` or `SUSPENDED` state, the procedure completes immediately without performing any attach.
- `(RTL33b)` If the channel is in the `INITIALIZED`, `DETACHED`, `DETACHING`, or `ATTACHING` state, perform an implicit attach per [RTL4](#RTL4) and wait for it to complete
- `(RTL33b1)` If the implicit attach fails (for example, the channel transitions to the `FAILED` state, or the underlying attach is otherwise rejected), the procedure MUST reject with the same `ErrorInfo` that caused the attach to fail
- `(RTL33c)` If the channel is in the `FAILED` state, the procedure MUST throw an `ErrorInfo` with `statusCode` 400 and `code` 90001, indicating that the channel operation failed due to the current channel state

### RealtimePresence {#realtime-presence}

Expand Down Expand Up @@ -913,8 +918,9 @@ The threading and/or asynchronous model for each realtime library will vary by l
- `(RTP10e)` In all other ways, this method is identical to `RealtimePresence#enter` and should have matching tests
- `(RTP11)` `RealtimePresence#get` function:
- `(RTP11a)` Returns the list of current members on the channel in a callback. By default, will wait for the `SYNC` to be completed, see [RTP11c1](#RTP11c1)
- `(RTP11b)` Implicitly attaches the `RealtimeChannel` if the channel is in the `INITIALIZED` state. However, if the channel is in or enters the `DETACHED` or `FAILED` state before the operation succeeds, it will result in an error
- `(RTP11b)` This clause has been replaced by [RTP11e](#RTP11e)
- `(RTP11d)` If the `RealtimeChannel` is in the `SUSPENDED` state then the `get` function will by default, or if `waitForSync` is set to `true`, result in an error with `code` `91005` and a `message` stating that the presence state is out of sync due to the channel being in a `SUSPENDED` state. If however the `get` function is called with `waitForSync` set to `false`, then it immediately returns the members currently stored in the `PresenceMap` giving developers access to the members that were present at the time the channel became `SUSPENDED`
- `(RTP11e)` Perform the *ensure-active-channel* procedure ([RTL33](#RTL33)) on the underlying `RealtimeChannel`. Note that [RTP11d](#RTP11d) takes precedence over current spec point [RTP11e](#RTP11e)
- `(RTP11c)` An optional set of params can be provided:
- `(RTP11c1)` `waitForSync` (default `true`). When `true`, method will wait until `SYNC` is complete before returning a list of members. When `false`, known set of presence members is returned immediately, which may be incomplete if the `SYNC` is not finished
- `(RTP11c2)` `clientId` filters members by the provided `clientId`
Expand Down
3 changes: 2 additions & 1 deletion specifications/objects-features.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,8 @@ Objects feature enables clients to store shared data as "objects" on a channel.

- `(RTO1)` `RealtimeObjects#getRoot` function:
- `(RTO1a)` Requires the `OBJECT_SUBSCRIBE` channel mode to be granted per [RTO2](#RTO2)
- `(RTO1b)` If the channel is in the `DETACHED` or `FAILED` state, the library should throw an `ErrorInfo` error with `statusCode` 400 and `code` 90001
- `(RTO1b)` This clause has been replaced by [RTO1e](#RTO1e)
- `(RTO1e)` Perform the *ensure-active-channel* procedure ([RTL33](../features#RTL33)) on the underlying `RealtimeChannel`.
- `(RTO1c)` If the [RTO17](#RTO17) sync state is not `SYNCED`, waits for the sync state to transition to `SYNCED`
- `(RTO1d)` Returns the object with id `root` from the internal `ObjectsPool` as a `LiveMap`
- `(RTO11)` `RealtimeObjects#createMap` function:
Expand Down
Loading