Repository navigation
Conversation
* test(repo): assert the token date and signature policy (FLU-1083) The SDK refreshes the token on code 40 only. A token used before its issue date (42) is reconnected as-is until the server's clock catches up, and a bad signature (43) is not retried with a new token. The four tests now assert that instead of a refresh. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(repo): tighten the token date and signature tests (FLU-1083) Keep the invalid window open past the refresh so the refreshed token is always rejected, count token requests through an env assertion, and fix the step and file comments to match what the tests assert. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(repo): drop the token signature after login test (FLU-1083) A signing secret doesn't go bad mid-session, and the test only timed the SDK's reconnect backoff. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(repo): keep the login error across the loading screen (FLU-1083) The chooser page is replaced while connecting, so an error it stored itself was gone by the time the login failed. The auth state now carries it, and the rebuilt page shows it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012vTgFwqhUc2wKCWrw635yC --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(ui): keep the footer of a sent message before a failed one (FLU-1090) A message that failed now starts its own group, so the sent message before it keeps its timestamp and delivery status. Consecutive failed messages still group together. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * docs(ui): describe every failed message in the changelog (FLU-1090) Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012vTgFwqhUc2wKCWrw635yC --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
… from it (FLU-1085) Hiding a channel, or the current user being removed from it, disposed the Channel, so a page still holding it crashed on its next read. The channel now stays alive and only leaves StreamChatClient.state.channels; a later watch, query or channel.visible brings it back. Channel.hidden follows the hidden and visible events, and the current user's membership is cleared on removal. ChannelState.copyWith(membership: null) now clears the membership. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012vTgFwqhUc2wKCWrw635yC
Contributor
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: true
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 |
Correct the comment on when a hidden channel comes back, drop a test that guarded nothing, mention plain hiding in the UI changelog, and wrap long lines. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012vTgFwqhUc2wKCWrw635yC
…-channel-page-crashes-after-its-channel-is-disposed-user # Conflicts: # e2e_app/integration_test/channel_actions_test.dart # e2e_app/integration_test/message_actions_test.dart # e2e_app/integration_test/moderation_test.dart # packages/stream_chat_flutter/CHANGELOG.md
…-channel-page-crashes-after-its-channel-is-disposed-user # Conflicts: # packages/stream_chat/CHANGELOG.md # packages/stream_chat_flutter/CHANGELOG.md
…-channel-page-crashes-after-its-channel-is-disposed-user # Conflicts: # packages/stream_chat_flutter/CHANGELOG.md
…-channel-page-crashes-after-its-channel-is-disposed-user # Conflicts: # packages/stream_chat/CHANGELOG.md # packages/stream_chat_flutter/CHANGELOG.md
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An open channel page crashed when its channel was hidden or the current user was removed from it. Blocking someone triggers the hide too: the backend hides 1-on-1 channels with the blocked user. The client disposed the
Channelonchannel.hiddenand on the current user'smember.removed/notification.removed_from_channel. The page kept the disposed instance and threw on its next read: the header'smemberCountwhen going back, andchannel.configwhen long-pressing a message.Fixes FLU-1085.
Hiding the open channel from a second client signed in as the same user (sample app, Android):
What changed (
stream_chat)StreamChatClient.state.channels, without disposing it.client.state.channelsandchannelsStreamcontain exactly what they did before.channel.deletedstill disposes.client.channel()andqueryChannelslook up every live channel, so they return the instance a page already holds instead of creating a second one.watch(), aqueryChannelsresult orchannel.visibleputs the channel back inclient.state.channels. A paginatedquery()doesn't.Channel.hiddennow followschannel.hiddenandchannel.visible, and the current user'smembershipis cleared when they're removed.ChannelState.copyWith(membership: null)now clears the membership, ascopyWith(draft: null)already did. Leavingmembershipout still keeps it, and channel updates without a membership still keep the current one.The iOS, Android and JS SDKs don't dispose a channel on hide or removal either. They update its hidden flag and membership and keep the screen alive.
How it was verified
stream_chattests, throughclient.handleEvent,client.state.channelsandclient.channel(). They cover hide, removal, deletion of a hidden channel, the way back, one instance per cid, membership, the hidden flag and thecopyWithcontract. Each of 19 guards was broken on purpose and a test caught it.stream_chat(2,052) andstream_chat_flutter_core(398) pass.stream_chat_flutterpasses apart from the local macOS goldens.🤖 Generated with Claude Code
https://claude.ai/code/session_012vTgFwqhUc2wKCWrw635yC