Skip to content

fix(mobile): refresh live thread replies on websocket fallback - #1

Draft
IcantCode1010 wants to merge 1 commit into
mainfrom
agent/fix-mobile-live-thread-refresh
Draft

fix(mobile): refresh live thread replies on websocket fallback#1
IcantCode1010 wants to merge 1 commit into
mainfrom
agent/fix-mobile-live-thread-refresh

Conversation

@IcantCode1010

Copy link
Copy Markdown
Owner

What changed

  • invalidate cached mobile thread queries before selecting the channel-window or websocket history path
  • preserve the existing channel-window storage and broadcast-rendering behavior
  • add a regression test for a live reply received after the client falls back to websocket history

Why

threadRepliesProvider is a one-shot future. Its invalidation previously ran only through the channel-window merge path, so a client that fell back to websocket history could receive a reply without refreshing an already-open thread. Restarting the app rebuilt the provider and revealed the missing reply.

User impact

Open threads refresh when live replies arrive on the websocket fallback path, without requiring the mobile app to restart.

Security review

The change adds no dependencies, permissions, storage, logging, deep links, or Android components. It invalidates only channel-scoped thread queries for existing channel timeline reply kinds and retains the current relay query filters and event handling.

Verification

  • dart format --output=none --set-exit-if-changed .
  • flutter analyze
  • flutter test test/features/channels/channel_messages_provider_test.dart (16 passed)
  • flutter test (1,089 passed, 1 skipped)
  • git diff --check

Related upstream issue: block#3046
Related upstream work: block#3243

Signed-off-by: IcantCode1010 <86989251+IcantCode1010@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant