[ECO-5196] Message edit/delete #100
Conversation
|
Warning Rate limit exceeded@sacOO7 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 5 minutes and 27 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughThis pull request refines chat message handling by updating the ChatApi logic, enhancing message construction, and improving error management. New methods to update and delete messages have been added, and the Message data class now includes versioning, timestamp, and operational details. The EventTypes definitions have been updated for consistent naming, and the Messages interface now supports update and delete operations. Several tests and integration suites have been revised or added to validate these changes, while metadata handling has been refined and the ably library version has been upgraded. Changes
Possibly related PRs
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
- Updated usages across roomreactions, messages and chatAPI to use JsonObject
sacOO7
force-pushed
the
feature/message-edit-update
branch
from
2883beb to
8cf8d51
Compare
Code Coverage
|
1. Added separate typealias for OperationMetadata 2. Defined messages operation param data classes, UpdateMessageParams and DeleteMessageParams
1. Updated Messages interface, added methods for message update and delete
sacOO7
force-pushed
the
feature/message-edit-update
branch
from
c9c1c98 to
d78946f
Compare
1. Added new fields version, timestamp and operation 2. Added method to decode JsonObject into Message.Operation 3. Updated/fixed tests accordingly
sacOO7
force-pushed
the
feature/message-edit-update
branch
from
bfade60 to
d36ac65
Compare
- Added impl for updateMessage anddeleteMessage - Added missing impl. for message update and delete - Refactored relevant code to have support for message update and delete actions
… tests - Added map for messageActionToEventType, used the same for emitting related message create, update and delete events - Refactored SandboxTest.kt, moved all of tests under `integration` package.
sacOO7
force-pushed
the
feature/message-edit-update
branch
from
8db641b to
44cd11b
Compare
sacOO7
force-pushed
the
feature/message-edit-update
branch
from
44cd11b to
a5bb0fc
Compare
sacOO7
force-pushed
the
feature/message-edit-update
branch
from
a5bb0fc to
5abc0bb
Compare
- Renamed message edit/delete description param to opDescription - Updated response fields for send and update message - Refactored tests for sending and retriving message history - Added test for updating a sent message - Added test for deleting a sent message
sacOO7
force-pushed
the
feature/message-edit-update
branch
from
5abc0bb to
b20593e
Compare
1. Marked message headers as nullable, this is needed for MessageCopy during message update operation 2. Added extension method `copy` to message that returns copy for a message with text as mandatory and metadata, headers as optional params 3. Refactored messages.update method signature to use MessageCopy, updated tests accordingly
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (9)
chat-android/src/main/java/com/ably/chat/ChatApi.kt (1)
156-156: Potential confusion in error message text.
“Occupancy endpoint returned empty value” might be too vague if the server returns an error or differently structured response. Provide additional context or logging as needed for easier debugging.chat-android/src/test/java/com/ably/chat/integration/MessagesIntegrationTest.kt (3)
25-42: Consider test coverage for edge cases.
The test checks a simple message round trip. You might also want to verify behavior for empty or null text, large payloads, etc.
48-89: Extensive property checks are good; verify performance.
This test eagerly checks each field. While thorough, it can be slow or repetitive if you add more tests. You may consider a shared helper to compare messages more concisely.
95-140: All messages remain in history, including updated/deleted ones.
This test logic aligns with the retrieved learnings regarding immutable messages. Confirm that the application’s UI or clients reflect updates/deletions properly in user-facing views.chat-android/src/main/java/com/ably/chat/Message.kt (2)
74-98: New properties expand message versioning and operation details.
This approach is flexible but doubles the fields for creation and versioning timestamps. Carefully manage them to avoid confusion about which time or version to display in different contexts.
109-123: Check redundancy between Message and MessageCopy.
Maintaining two data classes with overlapping fields can be error-prone. Ensure they remain synchronized if their schemas evolve.chat-android/src/main/java/com/ably/chat/Messages.kt (3)
86-86: Consider using a more descriptive type name thanMessageCopy.The type
MessageCopyis not immediately clear in its purpose or structure. Consider using a more descriptive name likeMessageUpdateorEditableMessageto better convey its intent.
356-357: Enhance error handling for unknown message actions.The error message could be more descriptive. Consider including the list of supported actions in the error message.
- ?: throw clientError("Received Unknown message action ${pubSubMessage.action}") + ?: throw clientError("Received unsupported message action '${pubSubMessage.action}'. Supported actions: ${messageActionToEventType.keys.joinToString()}")
463-463: Consider explicit null handling for metadata.The
getAsJsonObjectcall might return null. Consider usingget("metadata")?.asJsonObjectfor more explicit null handling.- metadata = data.getAsJsonObject("metadata"), + metadata = data.get("metadata")?.asJsonObject,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
chat-android/src/main/java/com/ably/chat/ChatApi.kt(2 hunks)chat-android/src/main/java/com/ably/chat/Message.kt(3 hunks)chat-android/src/main/java/com/ably/chat/Messages.kt(9 hunks)chat-android/src/test/java/com/ably/chat/ChatApiTest.kt(6 hunks)chat-android/src/test/java/com/ably/chat/integration/MessagesIntegrationTest.kt(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- chat-android/src/test/java/com/ably/chat/ChatApiTest.kt
🧰 Additional context used
🧠 Learnings (1)
chat-android/src/test/java/com/ably/chat/integration/MessagesIntegrationTest.kt (1)
Learnt from: sacOO7
PR: ably/ably-chat-kotlin#100
File: chat-android/src/test/java/com/ably/chat/integration/MessagesIntegrationTest.kt:203-250
Timestamp: 2025-02-14T13:26:06.027Z
Learning: In the Ably Chat Kotlin SDK, all messages (including deleted ones) are preserved in history as immutable events/records. Message deletion is implemented as a soft delete operation that adds a deletion event rather than removing the message from history.
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: check
- GitHub Check: build
- GitHub Check: coverage
🔇 Additional comments (16)
chat-android/src/main/java/com/ably/chat/ChatApi.kt (5)
36-38: Watch for potential null or non-object values when retrieving operation JSON.
getAsJsonObject(MessageProperty.OPERATION)may throw if the property is absent or not an actual JSON object. Consider a safer approach or ensure the API always returns a well-formed JSON object.
41-52: Ensure proper validation for required fields in message JSON.
All fields used in theMessageconstructor are mandatory. If the server omits any, the code may fail or raise unexpected exceptions.
60-84: Clarify the usage of version and timestamp in sendMessage.
Here,versionis set to the same value asserial, andtimestampusescreatedAt. Confirm that this approach is consistent with your versioning strategy and does not conflict with future edits or deletions.
87-115: Validation of updateMessage response.
The updated message is constructed assuming the response hasversionandtimestamp. If these fields are missing or malformed, the code may throw. Ensure consistent server-side behavior or add fallback handling.
117-145: Soft-delete logic aligns with the learned approach but confirm consistency.
Deletion setsaction = MESSAGE_DELETEwhile preserving the original message data, matching the practice of retaining message history. Double-check that this is desired in all scenarios and that any UI or downstream logic interprets it properly.chat-android/src/test/java/com/ably/chat/integration/MessagesIntegrationTest.kt (3)
146-198: Test covers message update flows well.
You might also verify partial updates (e.g., only metadata changes) if that’s allowed. Otherwise, this ensures both text and metadata changes are captured.
204-250: Test logic correctly verifies soft delete scenario.
Given the SDK's approach preserves deleted messages in history, ensuring theactionisMESSAGE_DELETEis sufficient. No concerns here.
252-260: Potential concurrency checks in test setup.
If multiple tests run in parallel, ensure that each test uses a distinct room or environment. This is typically best practice for integration tests that rely on external resources.chat-android/src/main/java/com/ably/chat/Message.kt (6)
3-4: Imports look fine.
Ensure that the standardMessagefromio.ably.lib.types.Messagedoes not conflict with yourcom.ably.chat.Messageclass.
100-108: Utility copy function might be prone to partial updates.
Ensure that any omitted properties incopy(...)reflect intended partial changes. Otherwise, you might want a single method that merges them carefully.
125-144: buildMessageOperation(jsonObject) could skip invalid properties.
Currently, all fields inmetadataObjectare converted to strings. Handle numeric or Boolean properties carefully, or consider type checks if required.
146-152: buildMessageOperation(clientId, ...) approach is consistent.
No immediate concerns, but if future complexities arise (e.g., typed metadata), a more structured approach may be preferable.
154-169: MessageProperty object is well-structured.
Ensures uniform references to JSON keys. No concerns.
171-178: MessageOperationProperty object is consistent with the code usage.
Keeps operation field definitions centralized. Approved.chat-android/src/main/java/com/ably/chat/Messages.kt (2)
211-265: Well-structured implementation of message operation data classes!The implementation is clean, well-documented, and follows a consistent pattern for both the data classes and their JSON conversion methods.
403-434: Clean implementation of message operations!The implementations are concise, consistent, and properly map parameters to their respective data classes.
1. Marked metadata field as non-nullable 2. Updated unit tests accordingly
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
chat-android/src/main/java/com/ably/chat/Message.kt (2)
100-123: Consider adding validation in MessageCopy.While the MessageCopy implementation is good, consider adding validation to ensure that either metadata or headers is provided when copying a message.
data class MessageCopy( val message: com.ably.chat.Message, val text: String, val metadata: MessageMetadata? = null, val headers: MessageHeaders? = null, ) { + init { + require(metadata != null || headers != null) { + "At least one of metadata or headers must be provided when copying a message" + } + } val serial: String = message.serial // ... rest of the properties }
125-152: Consider making buildMessageOperation functions internal.These utility functions should be marked as internal since they're implementation details.
-fun buildMessageOperation(jsonObject: JsonObject?): Message.Operation? { +internal fun buildMessageOperation(jsonObject: JsonObject?): Message.Operation? { -fun buildMessageOperation(clientId: String, description: String?, metadata: Map<String, String>?): Message.Operation { +internal fun buildMessageOperation(clientId: String, description: String?, metadata: Map<String, String>?): Message.Operation {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
chat-android/src/main/java/com/ably/chat/Message.kt(4 hunks)chat-android/src/main/java/com/ably/chat/Messages.kt(9 hunks)chat-android/src/test/java/com/ably/chat/ChatApiTest.kt(6 hunks)chat-android/src/test/java/com/ably/chat/MessagesTest.kt(7 hunks)chat-android/src/test/java/com/ably/chat/RoomReactionsTest.kt(2 hunks)example/src/main/java/com/ably/chat/example/MainActivity.kt(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- chat-android/src/test/java/com/ably/chat/ChatApiTest.kt
- example/src/main/java/com/ably/chat/example/MainActivity.kt
- chat-android/src/main/java/com/ably/chat/Messages.kt
🧰 Additional context used
🧠 Learnings (1)
chat-android/src/test/java/com/ably/chat/RoomReactionsTest.kt (2)
Learnt from: sacOO7
PR: ably/ably-chat-kotlin#100
File: chat-android/src/main/java/com/ably/chat/RoomReactions.kt:156-156
Timestamp: 2025-02-14T13:27:05.487Z
Learning: The server always ensures that the metadata field in room reactions is sent as a JsonObject, eliminating the need for explicit type checking on the client side.
Learnt from: sacOO7
PR: ably/ably-chat-kotlin#66
File: chat-android/src/test/java/com/ably/chat/RoomReactionsTest.kt:44-50
Timestamp: 2024-11-28T11:08:42.524Z
Learning: The test cases for verifying behavior when the room is not in the ATTACHED state are covered in `chat-android/src/test/java/com/ably/chat/room/RoomEnsureAttachedTest.kt`.
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: check
- GitHub Check: coverage
- GitHub Check: build
🔇 Additional comments (6)
chat-android/src/test/java/com/ably/chat/RoomReactionsTest.kt (1)
75-75: LGTM! Changes align with server behavior.The changes correctly reflect that metadata is always provided as a JsonObject by the server, as confirmed by the retrieved learnings.
Also applies to: 99-99
chat-android/src/test/java/com/ably/chat/MessagesTest.kt (2)
57-58: LGTM! Using MessageProperty constants improves maintainability.Using constants from MessageProperty for property names reduces the risk of typos and makes future property name changes easier.
79-81: LGTM! Comprehensive test coverage for new message properties.The test cases properly validate the new version and timestamp properties, and consistently initialize metadata as a JsonObject across all test scenarios.
Also applies to: 109-109, 126-126, 143-144, 244-244, 254-254
chat-android/src/main/java/com/ably/chat/Message.kt (3)
59-59: LGTM! Improved type safety with metadata and headers.The changes correctly reflect that:
- metadata is always present (non-nullable)
- headers are optional (nullable)
Also applies to: 74-74
82-98: LGTM! Well-documented message versioning properties.The new properties (version, timestamp, operation) are well-documented and align with the PR objectives for implementing message edit/delete functionality.
157-178: LGTM! Well-organized property constants.The MessageProperty and MessageOperationProperty objects provide a clean way to manage property names and improve maintainability.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
chat-android/src/main/java/com/ably/chat/Messages.kt (1)
1-1: Consider a more targeted suppression approach.File-level suppressions make the rule ineffective for the entire file. Consider more targeted suppressions at the class or function level where needed.
-@file:Suppress("StringLiteralDuplication")
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
chat-android/src/main/java/com/ably/chat/ChatApi.kt(2 hunks)chat-android/src/main/java/com/ably/chat/EventTypes.kt(2 hunks)chat-android/src/main/java/com/ably/chat/Message.kt(4 hunks)chat-android/src/main/java/com/ably/chat/Messages.kt(9 hunks)chat-android/src/test/java/com/ably/chat/ChatApiTest.kt(6 hunks)chat-android/src/test/java/com/ably/chat/MessagesTest.kt(7 hunks)chat-android/src/test/java/com/ably/chat/integration/MessagesIntegrationTest.kt(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- chat-android/src/main/java/com/ably/chat/EventTypes.kt
- chat-android/src/test/java/com/ably/chat/ChatApiTest.kt
- chat-android/src/test/java/com/ably/chat/integration/MessagesIntegrationTest.kt
🧰 Additional context used
🧠 Learnings (2)
chat-android/src/main/java/com/ably/chat/ChatApi.kt (2)
Learnt from: sacOO7
PR: ably/ably-chat-kotlin#100
File: chat-android/src/test/java/com/ably/chat/integration/MessagesIntegrationTest.kt:203-250
Timestamp: 2025-02-14T13:26:06.027Z
Learning: In the Ably Chat Kotlin SDK, all messages (including deleted ones) are preserved in history as immutable events/records. Message deletion is implemented as a soft delete operation that adds a deletion event rather than removing the message from history.
Learnt from: sacOO7
PR: ably/ably-chat-kotlin#75
File: chat-android/src/test/java/com/ably/chat/room/RoomFeatureSharedChannelTest.kt:43-45
Timestamp: 2024-12-02T12:10:18.954Z
Learning: In the `RoomFeatureSharedChannelTest.kt` tests, prefer using assertions like `Assert.assertEquals` that provide detailed error messages over general assertions like `Assert.assertTrue`, to aid in debugging when a test fails due to a missing mode.
chat-android/src/main/java/com/ably/chat/Message.kt (2)
Learnt from: sacOO7
PR: ably/ably-chat-kotlin#100
File: chat-android/src/test/java/com/ably/chat/integration/MessagesIntegrationTest.kt:203-250
Timestamp: 2025-02-14T13:26:06.027Z
Learning: In the Ably Chat Kotlin SDK, all messages (including deleted ones) are preserved in history as immutable events/records. Message deletion is implemented as a soft delete operation that adds a deletion event rather than removing the message from history.
Learnt from: sacOO7
PR: ably/ably-chat-kotlin#75
File: chat-android/src/test/java/com/ably/chat/room/RoomFeatureSharedChannelTest.kt:43-45
Timestamp: 2024-12-02T12:10:18.954Z
Learning: In the `RoomFeatureSharedChannelTest.kt` tests, prefer using assertions like `Assert.assertEquals` that provide detailed error messages over general assertions like `Assert.assertTrue`, to aid in debugging when a test fails due to a missing mode.
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: coverage
- GitHub Check: build
- GitHub Check: check
🔇 Additional comments (20)
chat-android/src/main/java/com/ably/chat/ChatApi.kt (5)
36-52: Thorough implementation of message object creation.The message construction has been enhanced with additional properties like
version,timestamp, andoperation, which provides better message versioning and tracking capabilities. This aligns well with the message edit/delete functionality being implemented.
60-84: Simplified sendMessage implementation with proper error handling.The function now uses a more direct approach by leveraging
params.toJsonObject()for the request body and properly handles empty responses with a descriptive server error. The created message now includes version and timestamp information.
87-115: Well-implemented message update functionality.The
updateMessagemethod is a solid implementation that properly handles the update operation, including setting version and timestamp properties. The method aligns with the CHA-M8 specification and includes comprehensive error handling.
117-145: Soft delete implementation preserves message history.The implementation correctly handles message deletion as a soft delete operation, aligning with the learned context that all messages (including deleted ones) are preserved in history as immutable events/records. The method follows the CHA-M9 specification and includes proper error handling.
156-156: Consistent error handling approach.Changing from throwing an
AblyExceptionto using theserverErrorfunction ensures consistency in error handling across all API methods.chat-android/src/test/java/com/ably/chat/MessagesTest.kt (5)
57-59: Good use of MessageProperty constants.Using constants from
MessagePropertyfor property names improves maintainability and consistency.
79-83: Updated assertions to include version and timestamp.The test now properly validates the new version and timestamp properties added to the Message class.
109-110: Updated PubSubMessage construction with required fields.The PubSubMessage now includes metadata as a JsonObject and the version property, ensuring test alignment with implementation changes.
Also applies to: 126-127
140-147: Updated message event assertions with new properties.The assertions now validate that the message includes the non-nullable metadata and the new version and timestamp properties.
244-255: Updated buildDummyPubSubMessage helper with required fields.The helper function now correctly initializes metadata as a JsonObject and includes the version property, aligning with the Message class changes.
chat-android/src/main/java/com/ably/chat/Message.kt (5)
59-59: Adjusted metadata and headers nullability.The metadata property is now non-nullable while headers is nullable. This change aligns with how these fields are handled in realtime responses, as confirmed in the integration tests and previous review comments.
Also applies to: 74-74
82-97: Added version tracking capabilities to Message class.The new properties (version, timestamp, operation) enhance the message versioning capabilities, providing better support for message history tracking and edit/delete operations.
100-113: Useful copy method for message modification.The copy function provides a clean way to create modified versions of messages while preserving their identity, which is essential for the update operations.
115-134: Well-implemented message operation building functions.The
buildMessageOperationfunctions provide a flexible way to create operation objects from either a JsonObject or individual parameters, covering both deserialization and creation scenarios.Also applies to: 136-142
147-159: Good use of property constants to improve code readability.The
MessagePropertyandMessageOperationPropertyobjects centralize property names, making the code more maintainable and less prone to string literal errors.Also applies to: 164-168
chat-android/src/main/java/com/ably/chat/Messages.kt (5)
73-107: Well-documented Message update and delete APIs.The new methods are thoroughly documented, clearly explaining their behavior and parameters. The soft delete approach aligns with the learned context that all messages are preserved in history as immutable events/records.
211-218: Clean implementation of parameter classes and JSON conversion.The parameter classes and their JSON conversion functions provide a structured way to handle message operations, making the code more maintainable and less prone to errors.
Also applies to: 220-244, 246-265
356-374: Improved message event type handling.The code now correctly maps message actions to event types instead of ignoring non-create actions, enabling proper handling of update and delete events.
403-433: Well-structured message operation implementations.The implementations of
send,update, anddeletemethods cleanly delegate to the ChatApi while properly transforming the parameters, ensuring consistent behavior across the application.
455-464: Updated message data parsing with non-nullable metadata.The
PubSubMessageDataclass and parsing function now handle metadata as a non-nullable JsonObject, aligning with the changes in the Message class.
…sageCopy used Message class instead
sacOO7
force-pushed
the
feature/message-edit-update
branch
from
4334624 to
fbac777
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
chat-android/src/main/java/com/ably/chat/ChatApi.kt(2 hunks)chat-android/src/main/java/com/ably/chat/EventTypes.kt(2 hunks)chat-android/src/main/java/com/ably/chat/Message.kt(4 hunks)chat-android/src/main/java/com/ably/chat/Messages.kt(9 hunks)chat-android/src/test/java/com/ably/chat/ChatApiTest.kt(6 hunks)chat-android/src/test/java/com/ably/chat/MessagesTest.kt(7 hunks)chat-android/src/test/java/com/ably/chat/integration/MessagesIntegrationTest.kt(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- chat-android/src/test/java/com/ably/chat/ChatApiTest.kt
- chat-android/src/main/java/com/ably/chat/EventTypes.kt
- chat-android/src/main/java/com/ably/chat/Message.kt
- chat-android/src/test/java/com/ably/chat/integration/MessagesIntegrationTest.kt
🧰 Additional context used
🧠 Learnings (1)
chat-android/src/main/java/com/ably/chat/ChatApi.kt (2)
Learnt from: sacOO7
PR: ably/ably-chat-kotlin#100
File: chat-android/src/test/java/com/ably/chat/integration/MessagesIntegrationTest.kt:203-250
Timestamp: 2025-02-14T13:26:06.027Z
Learning: In the Ably Chat Kotlin SDK, all messages (including deleted ones) are preserved in history as immutable events/records. Message deletion is implemented as a soft delete operation that adds a deletion event rather than removing the message from history.
Learnt from: sacOO7
PR: ably/ably-chat-kotlin#75
File: chat-android/src/test/java/com/ably/chat/room/RoomFeatureSharedChannelTest.kt:43-45
Timestamp: 2024-12-02T12:10:18.954Z
Learning: In the `RoomFeatureSharedChannelTest.kt` tests, prefer using assertions like `Assert.assertEquals` that provide detailed error messages over general assertions like `Assert.assertTrue`, to aid in debugging when a test fails due to a missing mode.
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: coverage
- GitHub Check: build
- GitHub Check: check
🔇 Additional comments (16)
chat-android/src/main/java/com/ably/chat/ChatApi.kt (5)
36-52: Improved message construction with structured property extractionThe refactoring to use
messageJsonObjectfor property extraction improves code organization and readability. The addition of new fields likeversion,timestamp, andoperationproperly supports the message editing and deletion features.
61-84: Clean approach to message sendingThe method has been simplified by using
params.toJsonObject()and improved with proper version and timestamp handling. The error handling now uses a consistentserverErrorapproach instead of directly throwing exceptions.
87-115: Well-implemented message update functionalityThe new
updateMessagemethod follows a consistent pattern with other API methods. It properly extracts version and timestamp from the response and builds a new Message with the updated fields and appropriate operation details.
117-145: Message deletion follows soft delete patternThe implementation correctly follows the soft delete pattern mentioned in the retrieved learnings, where deleted messages remain in history as immutable events with a deletion marker.
156-156: Consistent error handlingThe error handling approach has been standardized across all methods by using
serverErrorinstead of direct exception throwing.chat-android/src/test/java/com/ably/chat/MessagesTest.kt (5)
57-59: Improved property referencing with constantsUsing
MessagePropertyconstants instead of string literals improves maintainability and reduces the chance of typos in property names.
79-81: Added version and timestamp properties to message assertionsThe test has been properly updated to validate the new version and timestamp fields that were added to the Message model.
110-110: Added metadata and version to PubSubMessage in testsThe test message now includes a proper JSON metadata object and version field, ensuring the test accurately represents real-world messages.
Also applies to: 126-126, 127-127
140-145: Updated message assertions with non-nullable metadataThe assertion now uses
MessageMetadata()instead ofnullfor metadata, which aligns with changes to make metadata non-nullable in the Message class (as mentioned in past review comments).
244-245: Updated dummy message builder with required fieldsThe
buildDummyPubSubMessagehelper has been properly updated to include the metadata JSON object and version property, ensuring tests use properly formatted messages.Also applies to: 254-255
chat-android/src/main/java/com/ably/chat/Messages.kt (6)
73-107: Well-documented message update and delete operationsThe documentation for these new methods is thorough and informative. It clearly explains the soft delete behavior and potential future changes, which is valuable for developers using this API.
211-265: Well-organized parameter classes and conversion functionsThe internal parameter classes and their JSON conversion functions are well-structured, making the message operations code cleaner and more maintainable.
356-374: Improved message event type handlingThe code now maps message actions to event types using
messageActionToEventTypeinstead of ignoring actions that aren'tMESSAGE_CREATE. This is a more flexible approach that supports the new message update and delete features.
403-407: Simplified message sending implementationThe
sendmethod has been refactored to use the new parameter structure, making the code more concise and consistent with the new update and delete operations.
409-433: Clean implementation of update and delete operationsThe implementations properly leverage the ChatApi methods while encapsulating the parameter construction logic. The pattern is consistent with the existing code.
455-464: Consistent handling of non-nullable metadataThe
PubSubMessageDataclass and its parsing function have been updated to make metadata non-nullable, which aligns with the learned behavior that the Ably system always provides an empty JSON object for metadata in the realtime response.
sacOO7
force-pushed
the
feature/message-edit-update
branch
from
042ce01 to
99a0fa2
Compare
1. Marked message headers as non-nullable to enforce library level defaults 2. Removed redudunt copy method, refactored update method signature 3. Removed filesuppress for notImplemented methods across files
sacOO7
force-pushed
the
feature/message-edit-update
branch
from
99a0fa2 to
e155a95
Compare
TODO's
Update public doc/ README for usage of messages edit/delete( will be done as a part of web docs )Summary by CodeRabbit
Summary by CodeRabbit
New Features
Chores