chore: cache inbox message opened#656
Conversation
Sample app builds 📱Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request. |
messaginginapp/src/main/java/io/customer/messaginginapp/gist/data/listeners/Queue.kt
Outdated
Show resolved
Hide resolved
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## feature/message-inbox-mvp #656 +/- ##
============================================================
Coverage ? 68.88%
Complexity ? 819
============================================================
Files ? 148
Lines ? 4580
Branches ? 616
============================================================
Hits ? 3155
Misses ? 1195
Partials ? 230 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
|
📏 SDK Binary Size Comparison Report
|
|
Build available to test |
|
|
|
|
| try { | ||
| logger.debug("Updating inbox message ${message.toLogString()} opened status to: $opened") | ||
| // Cache the opened status locally for 304 responses | ||
| inAppPreferenceStore.saveInboxMessageOpenedStatus(message.queueId, opened) |
There was a problem hiding this comment.
Cache is updated before the API call. If the network call fails, the cache reflects a state the server never acknowledged?. Also the iOS PR does the opposite, cache is only written inside the success callback (response.statusCode == 200). We should do the similar here?
There was a problem hiding this comment.
Updated to cache after successful api call only
| when { | ||
| (code == 204 || code == 304) -> handleNoContent(code) | ||
| latestMessagesResponse.isSuccessful -> handleSuccessfulFetch(latestMessagesResponse.body()) | ||
| latestMessagesResponse.isSuccessful -> handleSuccessfulFetch( |
There was a problem hiding this comment.
Could we add Queue-level tests for:
- fromCache=true applies cached opened status
- fromCache=false clears cached opened status and uses server value
- network failure on log calls does not mutate cache (if fix above is applied)
There was a problem hiding this comment.
Unfortunately there's no coverage for Queue at the moment either. I'll add coverage for this in later PRs.
|
|
closes: MBL-1548
Summary
Prevents inbox messages from reverting to "unread" when
304responses contain stale cached data by caching user's opened status locally and applying it on304responses, while clearing cache on fresh200responses.Changes
304response handling to keep status code as304instead of converting to200for better handling200(fresh) vs304(cached) responses inQueue.fetchUserMessages()fromCacheparameter tohandleSuccessfulFetch()to distinguish response typeslogOpenedStatus)304responses to preserve user's recent changes200responses (prefer server state)logDeleted)GistQueue,Queue, andInAppPreferenceStoretointernal(removed from public API)How to Test
Before
304)After
304)Note
Medium Risk
Touches message fetching and state reconciliation around HTTP caching (304 handling), so mistakes could cause incorrect inbox read/unread state or stale overrides persisting.
Overview
Prevents inbox messages from reverting to unread when the message poll returns cached data by caching per-message opened state locally and reapplying it when responses are served from cache.
Queue.fetchUserMessages()now tags 304-derived responses (via a custom header after converting 304->200 for Retrofit), distinguishes cached vs fresh fetches, and on cached fetches overlays the locally stored opened flag onto mappedInboxMessages; on fresh 200s it clears the local override. Open/unopen actions persist the override to preferences, and deletions clear it. Public API surface is reduced by makingGistQueue/QueueandInAppPreferenceStoreinternal(reflected inmessaginginapp.api), and new preference-store behavior is covered by added unit tests.Written by Cursor Bugbot for commit dab9009. This will update automatically on new commits. Configure here.