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
Copy file name to clipboardExpand all lines: Sources/AblyChat/Errors.swift
+18-27Lines changed: 18 additions & 27 deletions
Original file line number
Diff line number
Diff line change
@@ -11,8 +11,6 @@ public let errorDomain = "AblyChatErrorDomain"
11
11
The error codes for errors in the ``errorDomain`` error domain.
12
12
*/
13
13
publicenumErrorCode:Int{
14
-
case nonspecific =40000
15
-
16
14
/// ``Rooms.get(roomID:options:)`` was called with a different set of room options than was used on a previous call. You must first release the existing room instance using ``Rooms.release(roomID:)``.
17
15
///
18
16
/// TODO this code is a guess, revisit in https://github.com/ably-labs/ably-chat-swift/issues/32
@@ -38,7 +36,6 @@ public enum ErrorCode: Int {
38
36
39
37
/// Has a case for each of the ``ErrorCode`` cases that imply a fixed status code.
40
38
internalenumCaseThatImpliesFixedStatusCode{
41
-
case nonspecific
42
39
case inconsistentRoomOptions
43
40
case messagesAttachmentFailed
44
41
case presenceAttachmentFailed
@@ -53,12 +50,9 @@ public enum ErrorCode: Int {
53
50
case roomInFailedState
54
51
case roomIsReleasing
55
52
case roomIsReleased
56
-
case roomInInvalidState
57
53
58
54
internalvartoNumericErrorCode:ErrorCode{
59
55
switchself{
60
-
case.nonspecific:
61
-
.nonspecific
62
56
case.inconsistentRoomOptions:
63
57
.inconsistentRoomOptions
64
58
case.messagesAttachmentFailed:
@@ -87,17 +81,14 @@ public enum ErrorCode: Int {
87
81
.roomIsReleasing
88
82
case.roomIsReleased:
89
83
.roomIsReleased
90
-
case.roomInInvalidState:
91
-
.roomInInvalidState
92
84
}
93
85
}
94
86
95
87
/// The ``ARTErrorInfo.statusCode`` that should be returned for this error.
96
88
internalvarstatusCode:Int{
97
89
// These status codes are taken from the "Chat-specific Error Codes" section of the spec.
98
90
switchself{
99
-
case.nonspecific,
100
-
.inconsistentRoomOptions,
91
+
case.inconsistentRoomOptions,
101
92
.roomInFailedState,
102
93
.roomIsReleasing,
103
94
.roomIsReleased:
@@ -112,18 +103,21 @@ public enum ErrorCode: Int {
112
103
.presenceDetachmentFailed,
113
104
.reactionsDetachmentFailed,
114
105
.occupancyDetachmentFailed,
115
-
.typingDetachmentFailed,
116
-
// CHA-RL9c
117
-
.roomInInvalidState:
106
+
.typingDetachmentFailed:
118
107
500
119
108
}
120
109
}
121
110
}
122
111
123
112
/// Has a case for each of the ``ErrorCode`` cases that do not imply a fixed status code.
124
113
internalenumCaseThatImpliesVariableStatusCode{
114
+
case roomInInvalidState
115
+
125
116
internalvartoNumericErrorCode:ErrorCode{
126
-
switchself{}
117
+
switchself{
118
+
case.roomInInvalidState:
119
+
.roomInInvalidState
120
+
}
127
121
}
128
122
}
129
123
}
@@ -169,8 +163,7 @@ internal enum ChatError {
169
163
case roomIsReleasing
170
164
case roomIsReleased
171
165
case presenceOperationRequiresRoomAttach(feature:RoomFeature)
172
-
case presenceOperationDisallowedForCurrentRoomStatus(feature:RoomFeature)
173
-
case roomInInvalidState(cause:ARTErrorInfo?)
166
+
case roomTransitionedToInvalidStateForPresenceOperation(cause:ARTErrorInfo?)
/// Waits until we can perform presence operations on the contributors of this room without triggering an implicit attach.
43
43
///
44
-
/// Implements the checks described by CHA-PR3d, CHA-PR3e, CHA-PR3f, and CHA-PR3g (and similar ones described by other functionality that performs contributor presence operations). Namely:
44
+
/// Implements the checks described by CHA-PR3d, CHA-PR3e, and CHA-PR3h (and similar ones described by other functionality that performs contributor presence operations). Namely:
45
45
///
46
-
/// - CHA-RL9, which is invoked by CHA-PR3d, CHA-PR10d, CHA-PR6c, CHA-T2c: If the room is in the ATTACHING status, it waits for the next room status change. If the new status is ATTACHED, it returns. Else, it throws an `ARTErrorInfo` derived from ``ChatError.roomInInvalidState(cause:)``.
46
+
/// - CHA-RL9, which is invoked by CHA-PR3d, CHA-PR10d, CHA-PR6c, CHA-T2c: If the room is in the ATTACHING status, it waits for the next room status change. If the new status is ATTACHED, it returns. Else, it throws an `ARTErrorInfo` derived from ``ChatError.roomTransitionedToInvalidStateForPresenceOperation(cause:)``.
47
47
/// - CHA-PR3e, CHA-PR10e, CHA-PR6d, CHA-T2d: If the room is in the ATTACHED status, it returns immediately.
48
-
/// - CHA-PR3f, CHA-PR10f, CHA-PR6e, CHA-T2e: If the room is in the DETACHED status, it throws an `ARTErrorInfo` derived from ``ChatError.presenceOperationRequiresRoomAttach(feature:)``.
49
-
/// - // CHA-PR3g, CHA-PR10g, CHA-PR6f, CHA-T2f: If the room is in any other status, it throws an `ARTErrorInfo` derived from ``ChatError.presenceOperationDisallowedForCurrentRoomStatus(feature:)``.
48
+
/// - CHA-PR3h, CHA-PR10h, CHA-PR6h, CHA-T2g: If the room is in any other status, it throws an `ARTErrorInfo` derived from ``ChatError.presenceOperationRequiresRoomAttach(feature:)``.
50
49
///
51
50
/// - Parameters:
52
51
/// - requester: The room feature that wishes to perform a presence operation. This is only used for customising the message of the thrown error.
Copy file name to clipboardExpand all lines: Sources/AblyChat/RoomLifecycleManager.swift
+3-6Lines changed: 3 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -1225,17 +1225,14 @@ internal actor DefaultRoomLifecycleManager<Contributor: RoomLifecycleContributor
1225
1225
// TODO: decide what to do if nextRoomStatusChange is nil; I believe that this will happen if the current Task is cancelled. For now, will just treat it as an invalid status change. Handle it properly in https://github.com/ably-labs/ably-chat-swift/issues/29
// Then: The call to `waitToBeAbleToPerformPresenceOperations(requestedByFeature:)` fails with a `roomInInvalidState` error, whose cause is the error associated with the room status change
2090
+
// Then: The call to `waitToBeAbleToPerformPresenceOperations(requestedByFeature:)` fails with a `roomInInvalidState` error with status code 500, whose cause is the error associated with the room status change
letexpectedCause=ARTErrorInfo(chatError:.attachmentFailed(feature:.messages, underlyingError: contributorAttachError)) // using our knowledge of CHA-RL1h4
// @specPartial CHA-PR3e - Tests the wait described in the spec point, but not that the feature actually performs this wait nor the side effect. TODO change this to a specOneOf once the feature is implemented
// @specPartial CHA-PR3f - Tests the wait described in the spec point, but not that the feature actually performs this wait. TODO change this to a specOneOf once the feature is implemented
2119
-
// @specPartial CHA-PR10f - Tests the wait described in the spec point, but not that the feature actually performs this wait. TODO change this to a specOneOf once the feature is implemented
2120
-
// @specPartial CHA-PR6e - Tests the wait described in the spec point, but not that the feature actually performs this wait. TODO change this to a specOneOf once the feature is implemented
2121
-
// @specPartial CHA-T2e - Tests the wait described in the spec point, but not that the feature actually performs this wait. TODO change this to a specOneOf once the feature is implemented
// Then: It throws a presenceOperationRequiresRoomAttach error for that feature (which we just check via its error code, i.e. `.nonspecific`, and its message)
2140
-
#expect(isChatError(caughtError, withCodeAndStatusCode:.fixedStatusCode(.nonspecific), message:"To perform this messages operation, you must first attach the room."))
2141
-
}
2142
-
2143
-
// @specPartial CHA-PR3f - Tests the wait described in the spec point, but not that the feature actually performs this wait. TODO change this to a specOneOf once the feature is implemented
2144
-
// @specPartial CHA-PR10f - Tests the wait described in the spec point, but not that the feature actually performs this wait. TODO change this to a specOneOf once the feature is implemented
2145
-
// @specPartial CHA-PR6e - Tests the wait described in the spec point, but not that the feature actually performs this wait. TODO change this to a specOneOf once the feature is implemented
2146
-
// @specPartial CHA-T2e - Tests the wait described in the spec point, but not that the feature actually performs this wait. TODO change this to a specOneOf once the feature is implemented
2118
+
// @specPartial CHA-PR3h - Tests the wait described in the spec point, but not that the feature actually performs this wait. TODO change this to a specOneOf once the feature is implemented
2119
+
// @specPartial CHA-PR10h - Tests the wait described in the spec point, but not that the feature actually performs this wait. TODO change this to a specOneOf once the feature is implemented
2120
+
// @specPartial CHA-PR6h - Tests the wait described in the spec point, but not that the feature actually performs this wait. TODO change this to a specOneOf once the feature is implemented
2121
+
// @specPartial CHA-T2g - Tests the wait described in the spec point, but not that the feature actually performs this wait. TODO change this to a specOneOf once the feature is implemented
// Then: It throws a presenceOperationDisallowedForCurrentRoomStatus error for that feature (which we just check via its error code, i.e. `.nonspecific`, and its message)
2165
-
#expect(isChatError(caughtError, withCodeAndStatusCode:.fixedStatusCode(.nonspecific), message:"This messages operation can not be performed given the current room status."))
2139
+
// Then: It throws a roomInInvalidState error for that feature, with status code 400, and a message explaining that the room must first be attached
2140
+
#expect(isChatError(caughtError, withCodeAndStatusCode:.variableStatusCode(.roomInInvalidState, statusCode:400), message:"To perform this messages operation, you must first attach the room."))
0 commit comments