Page MenuHomePhabricator

Update badge count on web and desktop taking into account thick threads
ClosedPublic

Authored by marcin on Aug 29 2024, 1:49 PM.
Tags
None
Referenced Files
F3301803: D13210.diff
Mon, Nov 18, 4:21 AM
Unknown Object (File)
Sat, Nov 9, 9:18 PM
Unknown Object (File)
Sat, Nov 9, 4:55 PM
Unknown Object (File)
Oct 18 2024, 9:37 PM
Unknown Object (File)
Oct 18 2024, 7:21 PM
Unknown Object (File)
Oct 18 2024, 5:17 PM
Unknown Object (File)
Oct 18 2024, 5:17 PM
Unknown Object (File)
Oct 18 2024, 5:17 PM
Subscribers

Details

Summary

This differential updates badge count on web and desktop according to the same semantics as the parent differential does on native.

Test Plan
  1. Apply this patch: https://gist.github.com/marcinwasowicz/2e56c2d67cd69b1ef279bc748ff1fb61
  2. Send messages from web client to desktop/web client.
  3. Ensure badge count stayes consistent and takes into account new thick threads.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

tomek added inline comments.
lib/selectors/thread-selectors.js
261 ↗(On Diff #43814)

This is no longer allUnreadCounts - it never was, but now we should probably name it e.g. thinThreadsUnreadCounts?

web/app.react.js
562 ↗(On Diff #43814)

Why do we change it from a hook to a component?

web/push-notif/badge-handler.react.js
24 ↗(On Diff #43814)

Maybe rename it to thinThreadsUnreadCount?

web/push-notif/notif-crypto-utils.js
604 ↗(On Diff #43814)

Is it really guaranteed that the notif has a threadID? Are we sure we want to have this invariant?

1346 ↗(On Diff #43814)

What is it for?

This revision is now accepted and ready to land.Aug 30 2024, 2:56 AM
web/app.react.js
562 ↗(On Diff #43814)

It hadn't worked if I just would have moved useBadgeHandler() here. Therefore I figured I had to refactor it into a component. The reason for moving it here is that now BadgeHandler is dependent on Tunnelbroker so it must be rendered after TunnelbrokerProvider is rendered.

web/push-notif/notif-crypto-utils.js
604 ↗(On Diff #43814)

It is guaranteed by flow types. If we are executing in this branch it means that we are processing thick thread notification. All thick thread notification types have obligatory threadID property. Therefore executing in this branch for notification that doesn't have threadID is a bug that we should be alarmed about.

1346 ↗(On Diff #43814)

This is extensively used in this file. localforage method to set multiple items at once sets new synchronization value after successful write. The role of this value is explained in detail in this comment: https://linear.app/comm/issue/ENG-8574/handle-the-race-condition-between-the-main-app-and-the-notification#comment-584caf12. The only difference is that the value is a string and instead of incrementing we just create brand new one.