Compute the state in a single place.
https://linear.app/comm/issue/ENG-8930/unify-the-approach-to-replies-count-and-unread-status-updates
Depends on D12975
Details
Details
- Reviewers
kamil inka - Commits
- rCOMMf9c63706bbd2: [lib] Extract read status operations logic
Processed an operation representing creation of a new thread with a viewer and a new user, created by that user. Checked if the thread was created and was set to unread.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- dmops
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| lib/shared/dm-ops/process-dm-ops.js | ||
|---|---|---|
| 74–75 ↗ | (On Diff #43145) | I didn't realize that the client code is able to ignore updateTypes.UPDATE_THREAD_READ_STATUS updates when their timestamp is too old. How does this work? |
| lib/shared/dm-ops/process-dm-ops.js | ||
|---|---|---|
| 74–75 ↗ | (On Diff #43145) | It isn't yet. It needs to be implemented as a part of https://linear.app/comm/project/handle-unordered-dm-operations-1bd291b0b628. We have to make sure that if user A opens a thread on device A1, then user B sends an update to device A2 about a new message, and then A1 sends an update to A2 about changing the thread to read, we don't accidentally mark the thread as read if the message from A1 is older than the message from B. But there are still more edge cases that need to be handled. |
| lib/shared/dm-ops/process-dm-ops.js | ||
|---|---|---|
| 74–75 ↗ | (On Diff #43145) | Makes sense, thanks for explaining. I wonder if ignoring outdated updateTypes.UPDATE_THREAD_READ_STATUS would be useful for thin threads too... I often discover weird behavior where one client shows a thread as unread, and another doesn't |
| lib/shared/dm-ops/process-dm-ops.js | ||
|---|---|---|
| 74–75 ↗ | (On Diff #43145) | Added a comment to https://linear.app/comm/issue/ENG-8751/add-a-timestamps-property-to-a-thick-thread-info to consider this. |