-
Notifications
You must be signed in to change notification settings - Fork 27
feat: In-App SSE #975
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
feat: In-App SSE #975
Conversation
Sample app builds 📱Below you will find the list of the latest versions of the sample apps. |
SDK binary size reports 📊SDK binary size of this PRSDK binary size diff report vs. main branch |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #975 +/- ##
==========================================
+ Coverage 65.40% 67.87% +2.46%
==========================================
Files 172 182 +10
Lines 8024 9400 +1376
==========================================
+ Hits 5248 6380 +1132
- Misses 2776 3020 +244 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| await setupInitialState() | ||
|
|
||
| logger.logWithModuleTag("SseLifecycleManager: Lifecycle manager started successfully", level: .info) | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SseLifecycleManager.start() not idempotent causes duplicate observers
The start() method in CioSseLifecycleManager is not idempotent. If called multiple times, setupNotificationObservers() appends additional observers to notificationObservers, and subscribeToSseFlagChanges()/subscribeToUserIdChanges() create new subscribers while orphaning old ones. While the singleton pattern makes this unlikely in production, calling start() multiple times would accumulate notification observers and cause duplicate handling of foreground/background events. Adding a guard like guard !hasStarted else { return } would make this method safe.
Collection of approved PRs for SSE implementation.
Note
Introduces SSE-based real-time delivery for in-app messages with robust lifecycle and reliability controls.
SseService(EventSource wrapper),SseConnectionManager,SseRetryHelper,HeartbeatTimer, and utilities (AsyncStreamBackport,Sleeper,ApplicationStateProvider)SseLifecycleManagerto start/stop SSE on app foreground/background and user identification changesuseSseandshouldUseSse; new actionsetSseEnabled; reducer/state updated accordinglyGistnow manages polling vs SSE: subscribes touseSse,userId, andpollInterval; stops polling when SSE active for identified users; continues polling for anonymous usersQueueManagerreadsx-gist-queue-polling-intervaland newx-cio-use-sseresponse header to update statesseAPIendpoints; DI graph updated to register new componentsLDSwiftEventSource(Podspec + SPM), and links it toCioMessagingInApptargetWritten by Cursor Bugbot for commit 2d878f0. This will update automatically on new commits. Configure here.