Fix messages not being sent after attachment upload completes in background

[VelikovPetar]

Goal

Fix a race condition where messages with attachments are never sent to the server after a successful CDN upload, causing them to disappear from the UI until the app is restarted.

Implementation

The attachment upload flow uses a WorkManager worker (UploadAttachmentsWorker) for the actual CDN upload and an in-memory coroutine observer (AttachmentsUploadStates) to bridge the result back to AttachmentsSender.waitForAttachmentsToBeSent(), which gates the doSendMessage call.

When the worker finds that all attachments are already uploaded (!hasPendingAttachment), it returned early without notifying AttachmentsUploadStates. This left the in-memory observer hanging indefinitely, so waitForAttachmentsToBeSent never completed and doSendMessage was never called.

This happens when:

1. The worker uploads attachments successfully but is killed before calling updateMessages()
2. On retry (reconnect or app restart), a new worker runs, reads the message from DB, sees all attachments already have UploadState.Success, and takes the early-return path — without signaling the observer

The fix adds AttachmentsUploadStates.updateMessageAttachments(message) to the early-return branch so the observer receives the success signal and doSendMessage proceeds.

UI Changes

No UI changes.

Testing

1. Send a message with an attachment
2. While the upload is in progress, toggle airplane mode or force-kill the app
3. Reopen the app or turn off airplane mode
4. Verify the message is sent successfully and appears in the message list

Summary by CodeRabbit

• Bug Fixes
  • Fixed attachment upload state tracking to ensure proper state updates in all message scenarios. Previously, when messages had no pending attachments awaiting upload, the system would not update attachment upload states. This has been corrected to maintain consistent and accurate upload status tracking across all cases.

[github-actions]

PR checklist ✅

All required conditions are satisfied:

• Title length is OK (or ignored by label).
• At least one pr: label exists.
• Sections ### Goal, ### Implementation, and ### Testing are filled.

🎉 Great job! This PR is ready for review.

[github-actions]

SDK Size Comparison 📏

SDK	Before	After	Difference	Status
stream-chat-android-client	5.26 MB	5.26 MB	0.00 MB	🟢
stream-chat-android-offline	5.49 MB	5.49 MB	0.00 MB	🟢
stream-chat-android-ui-components	10.64 MB	10.64 MB	0.00 MB	🟢
stream-chat-android-compose	12.87 MB	12.87 MB	0.00 MB	🟢

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 551218c5-5937-4c37-aebd-1b2e3e8eaf7f

📥 Commits

Reviewing files that changed from the base of the PR and between 4bb2eb4 and faa2451.

📒 Files selected for processing (1)

• stream-chat-android-client/src/main/java/io/getstream/chat/android/client/attachment/worker/UploadAttachmentsWorker.kt

---

Walkthrough

Added a call to AttachmentsUploadStates.updateMessageAttachments(message) in the early-exit path of UploadAttachmentsWorker when a message lacks pending attachments. This ensures attachment upload state tracking is properly updated before the worker returns success, rather than only logging and returning.

Changes

Cohort / File(s)	Summary
Attachment Upload State Tracking stream-chat-android-client/src/main/java/io/getstream/chat/android/client/attachment/worker/UploadAttachmentsWorker.kt	Added state update call in the no-pending-attachments early-exit path to ensure upload state is persisted before returning success.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

A rabbit's work is never done,
When attachments need their state updated, one by one.
No pending tasks, yet states must track,
Ensuring nothing falls through the cracks! 🐰📎

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main bug fix: preventing messages with attachments from being stuck unsent after background attachment upload completion.
Description check	✅ Passed	The description covers the Goal, Implementation, and Testing sections with detailed explanations of the race condition and fix. UI Changes section appropriately indicates no changes. Some optional checklist items are unchecked, but core content is complete.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch bug/AND-1138_fix_potential_attachment_uploads_race

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[stream-public-bot]

🚀 Available in v6.37.1