mirror of
https://github.com/block/buzz.git
synced 2026-11-14 13:21:02 +00:00
3dcdf1c056
Activity watched the whole relay session state, so it rebuilt, and downloaded its whole feed again, for every socket state on the way back from a reconnect: disconnected, reconnecting (once per attempt) and connected. Only the last of those reads could subscribe live; the others were thrown away. On an iPhone 12 mini signed in to Builderlab, every resume after the background grace period read the 25 KB feed three times. Activity now reads again once per new connection, the way the profile provider already does: it listens for the session becoming connected and rebuilds then. Losing the connection no longer rebuilds it, so the feed it already shows stays until the reconnect read replaces it. ### Validation New test: a disconnected, two reconnecting and a connected state read the feed once. It fails without this change (four reads). Full mobile test suite and `flutter analyze` pass. On the iPhone 12 mini (profile build with this change, signed in to Builderlab), 60 s in the background, then the first 20 s after resuming: | | Activity feed reads | Bytes | | --- | --- | --- | | Before | 3 | 74.8 KB | | After | 1 | 25.0 KB | After the resume, Activity's live subscriptions opened again, and opening Activity showed the mention posted just before the resume. The automated run covered a cold start, the home list, a 60 s background, the resume and opening Activity. ### Regressions - While the relay is unreachable, Activity keeps showing the feed it last read instead of reading over HTTP on each socket state. Once the socket connects again it reads and subscribes as before. Signed-off-by: Tom Brow <tomb@squareup.com> Co-authored-by: Tom Brow <tomb@squareup.com> Co-authored-by: studio <dc2fc481343672df31a689840c09299972e704dac592e0da6f18486646a7ee3e@buzz.block.builderlab.xyz>