Make resolveAttachmentFiles a suspend function#6321
Conversation
PR checklist ✅All required conditions are satisfied:
🎉 Great job! This PR is ready for review. |
SDK Size Comparison 📏
|
db52dd5 to
bbc6a54
Compare
|
WalkthroughThis change refactors attachment file resolution from a synchronous blocking function to an asynchronous suspend function. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
stream-chat-android-ui-common/src/main/kotlin/io/getstream/chat/android/ui/common/feature/messages/composer/MessageComposerController.kt (1)
718-722: ClarifyresolveAttachmentscontract insendMessageKDoc.Now that caller-side IO wrapping is removed, document that custom resolvers must handle their own dispatcher switching if they do blocking/IO work.
📝 Suggested KDoc addition
/** * Sends a given message using our Stream API. Based on [isInEditMode], we either edit an existing message, or we * send a new message, using [ChatClient]. In case the message is a moderated message the old one is deleted before * the replacing one is sent. * * It also dismisses any current message actions. * * `@param` message The message to send. + * `@param` callback Callback invoked with the send/edit result. + * `@param` resolveAttachments Optional suspending resolver invoked before send/edit. If it performs + * blocking or IO work, it should switch dispatcher internally. */As per coding guidelines: "Document public APIs with KDoc, including thread expectations and state notes".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@stream-chat-android-ui-common/src/main/kotlin/io/getstream/chat/android/ui/common/feature/messages/composer/MessageComposerController.kt` around lines 718 - 722, Update the KDoc for the public function sendMessage (MessageComposerController.sendMessage) to document the contract for the resolveAttachments suspend parameter: explain that resolveAttachments is invoked as provided by the caller and must itself handle dispatcher switching if it performs blocking or IO work (it will not be wrapped by the API), note it is a suspend function and may be called on the caller thread, and include a short thread/state expectation sentence so implementers know to use withContext(Dispatchers.IO) or similar for blocking operations.stream-chat-android-ui-common/src/main/kotlin/io/getstream/chat/android/ui/common/helper/internal/AttachmentStorageHelper.kt (1)
92-103: Add explicit threading contract toresolveAttachmentFilesKDoc.Since dispatching moved inside this public API, document that callers can invoke it from any context and IO is switched internally.
📝 Suggested KDoc tweak
/** * Resolves deferred attachments by copying their source content into local cache files. * * Attachments that already have a non-null [Attachment.upload] are returned unchanged. * For others, the original content URI is read from [EXTRA_SOURCE_URI] and copied to a * local cache file. Attachments whose source URI cannot be resolved (e.g. the content * URI is no longer accessible or the cache write fails) are **dropped** from the result. + * + * Threading: Safe to call from any coroutine context. File IO is dispatched internally + * to [DispatcherProvider.IO]. * * `@param` attachments The attachments to resolve. * `@return` Attachments with [Attachment.upload] populated for every entry that had a source URI. */As per coding guidelines: "Document public APIs with KDoc, including thread expectations and state notes".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@stream-chat-android-ui-common/src/main/kotlin/io/getstream/chat/android/ui/common/helper/internal/AttachmentStorageHelper.kt` around lines 92 - 103, The KDoc for resolveAttachmentFiles lacks an explicit threading contract; update the public KDoc for the resolveAttachmentFiles function to state callers may invoke it from any coroutine context and that the function internally switches to the IO dispatcher for blocking/IO work (so callers don't need to dispatch themselves), and include a short state note that attachments with missing/unresolvable source URIs are dropped; reference resolveAttachmentFiles and mention the internal IO dispatch behavior in that KDoc.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In
`@stream-chat-android-ui-common/src/main/kotlin/io/getstream/chat/android/ui/common/feature/messages/composer/MessageComposerController.kt`:
- Around line 718-722: Update the KDoc for the public function sendMessage
(MessageComposerController.sendMessage) to document the contract for the
resolveAttachments suspend parameter: explain that resolveAttachments is invoked
as provided by the caller and must itself handle dispatcher switching if it
performs blocking or IO work (it will not be wrapped by the API), note it is a
suspend function and may be called on the caller thread, and include a short
thread/state expectation sentence so implementers know to use
withContext(Dispatchers.IO) or similar for blocking operations.
In
`@stream-chat-android-ui-common/src/main/kotlin/io/getstream/chat/android/ui/common/helper/internal/AttachmentStorageHelper.kt`:
- Around line 92-103: The KDoc for resolveAttachmentFiles lacks an explicit
threading contract; update the public KDoc for the resolveAttachmentFiles
function to state callers may invoke it from any coroutine context and that the
function internally switches to the IO dispatcher for blocking/IO work (so
callers don't need to dispatch themselves), and include a short state note that
attachments with missing/unresolvable source URIs are dropped; reference
resolveAttachmentFiles and mention the internal IO dispatch behavior in that
KDoc.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 92f77cf3-9021-4bf9-b533-2760eba380fd
📒 Files selected for processing (4)
stream-chat-android-compose/src/test/kotlin/io/getstream/chat/android/compose/viewmodel/messages/MessageComposerViewModelTest.ktstream-chat-android-ui-common/src/main/kotlin/io/getstream/chat/android/ui/common/feature/messages/composer/MessageComposerController.ktstream-chat-android-ui-common/src/main/kotlin/io/getstream/chat/android/ui/common/helper/internal/AttachmentStorageHelper.ktstream-chat-android-ui-common/src/test/kotlin/io/getstream/chat/android/ui/common/helper/internal/AttachmentStorageHelperTest.kt


Goal
AttachmentStorageHelper.resolveAttachmentFileswas annotated@WorkerThreadbut passed around as asuspendlambda, making it look safe to call from any thread. Callers happened to wrap it inwithContext(DispatcherProvider.IO), but the responsibility was misplaced.Implementation
resolveAttachmentFilesasuspendfunction that switches toDispatcherProvider.IOinternally@WorkerThreadannotationwithContext(DispatcherProvider.IO)wrappers fromMessageComposerController.sendMessageandenqueueEditMessagerunTest/onBlocking🎨 UI Changes
None
Testing
Existing tests updated and passing
Summary by CodeRabbit
Refactor
Tests