- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 8 2024
Aug 7 2024
Aug 6 2024
In D12986#367417, @ashoat wrote:Great work on this!! You made the diff stack really easy to review
Aug 5 2024
In D12914#366648, @ashoat wrote:In D12914#366501, @ashoat wrote:Ok, let's add it for consistency, but it is still confusing. @ashoat do you know why MutableThickRawThreadInfo includes community?
This was my mistake. Would it be easy to remove at this point? We might consider a follow-up task for this if not.
This comment wasn't responded to. It looks like this diff was landing with support for the community column, which isn't ideal, but probably won't be an issue if nobody calls it with community set.
Still, at the very least I'd like to see a follow-up task created for removing community from ThickRawThreadInfo (and any related types).
Aug 2 2024
Run ops in parallel
Rename. Run ops in parallel.
Set the timestamp
Fix result check
Capitalize an acronym
Revert readonly
Bump the version
Bump the version
In D12921#366498, @ashoat wrote:Discussed something similar for updating unread status here.
- Updating the replies count happens through an update. If we extract the logic from the specs, we would need to inspect returned updates and modify or create a new one with the replies count update.
This is true, but we could implement a utility that handles it. I don't think it would be that complicated.
- Messages can be returned both in rawMessageInfos and as a part of some updateInfos.
Perhaps mergeUpdatesWithMessageInfos could be helpful here?
Each of these could be complicated, and it seems they mostly move complexity from one place to another.
Ultimately my goal would be to unify the complexity in one place, so we can mitigate the risk of the programmer forgetting to handle it in a specific case, and so we could reduce code duplication.
In D12881#366497, @ashoat wrote:In D12881#366279, @tomek wrote:In D12881#366124, @inka wrote:Should we set the unread status?
Yes, you're right!
I wonder if it would be better to handle this as a "side effect" of the main processDMOperation. We could take a similar approach to updating the replies count.
We would need to check all of the rawMessageInfos, as well as any messages in the updateInfos, to see if any new messages are introduced that aren't from the viewer. This could potentially be done in useProcessDMOperation. Potentially mergeUpdatesWithMessageInfos could be helpful for extracting the messages from the updates.
@tomek, what do you think? A unified approach would mitigate the risk of the programmer forgetting to handle it in a specific case, and it would reduce code duplication.
Delete unnecessary check
In D12835#366494, @ashoat wrote:I wonder if the AddMembers spec should be split into two: one for adding the viewer, and one for adding somebody else
Then when somebody adds a member, they'll send the first type to all of the added users' devices, and the second type to all of the existing users' devices
What do you think?