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
F3005751: D13210.id43876.diff
Fri, Oct 18, 5:17 PM
F3005750: D13210.id43867.diff
Fri, Oct 18, 5:17 PM
F3005749: D13210.id43839.diff
Fri, Oct 18, 5:17 PM
F3005748: D13210.id43814.diff
Fri, Oct 18, 5:17 PM
F3005629: D13210.diff
Fri, Oct 18, 5:15 PM
Unknown Object (File)
Thu, Oct 10, 12:01 PM
Unknown Object (File)
Tue, Oct 8, 10:00 PM
Unknown Object (File)
Tue, Oct 8, 3:50 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
Branch
marcin/eng-8243
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

tomek added inline comments.
lib/selectors/thread-selectors.js
261

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

web/app.react.js
562

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

web/push-notif/badge-handler.react.js
24

Maybe rename it to thinThreadsUnreadCount?

web/push-notif/notif-crypto-utils.js
604

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

1346

What is it for?

This revision is now accepted and ready to land.Aug 30 2024, 2:56 AM
web/app.react.js
562

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

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

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.