You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use the implementation of the RELEASE operation provided by the room
lifecycle manager, and implement the spec points relating to room map
bookkeeping and releasing the underlying realtime channels.
Based on [1] at 6f0740a.
I have not implemented the spec points that relate to making sure that a
room fetch waits for any previous room with the same ID to finish
releasing; this is a part of the spec which is in flux (currently
implemented via the INITIALIZING status, which was added to the spec
after we started implementing the room lifecycle manager and hasn’t been
implemented in this SDK yet, and soon to be further changed in the spec
by making room-getting async). We can look at the current state of
things when we come to do #66.
Part of #47.
[1] ably/specification#200
/// - forcedOperationID: Allows tests to force the operation to have a given ID. In combination with the ``testsOnly_subscribeToOperationWaitEvents`` API, this allows tests to verify that one test-initiated operation is waiting for another test-initiated operation.
// TODO: what to do here? (https://github.com/ably/specification/pull/200/files#r1837154563) — Andy replied that it’s a no-op but that this is going to be specified in an upcoming PR when we make room-getting async
// @spec CHA-RL3h - I haven’t explicitly tested that `performReleaseOperation()` happens _before_ releasing the channels (i.e. the “upon operation completion” part of the spec point), because it would require me to spend extra time on mock-writing which I can’t really afford to spend right now. I think we can live with it at least for the time being; I’m pretty sure there are other tests where the spec mentions or requires an order where I also haven’t tested the order.
Copy file name to clipboardExpand all lines: Tests/AblyChatTests/DefaultRoomsTests.swift
+41Lines changed: 41 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -3,6 +3,8 @@ import Testing
3
3
4
4
// The channel name of basketball::$chat::$chatMessages is passed in to these tests due to `DefaultRoom` kicking off the `DefaultMessages` initialization. This in turn needs a valid `roomId` or else the `MockChannels` class will throw an error as it would be expecting a channel with the name \(roomID)::$chat::$chatMessages to exist (where `roomId` is the property passed into `rooms.get`).
5
5
structDefaultRoomsTests{
6
+
// MARK: - Get a room
7
+
6
8
// @spec CHA-RC1a
7
9
@Test
8
10
func get_returnsRoomWithGivenID()asyncthrows{
@@ -78,4 +80,43 @@ struct DefaultRoomsTests {
78
80
// Then: It throws an inconsistentRoomOptions error
// When: `release(roomID:)` is called with this room ID
110
+
_ =tryawait rooms.release(roomID: roomID)
111
+
112
+
// Then:
113
+
// 1. first, the room is removed from the room map
114
+
// 2. next, `release` is called on the room
115
+
116
+
// These two lines are convoluted because the #require macro has a hard time with stuff of type Bool? and emits warnings about ambiguity unless you jump through the hoops it tells you to
0 commit comments