Fix race conditions around threads #2331
Conversation
…chguy/fix/21627 � Conflicts: � src/client.ts
t3chguy
added
Dependencies
| ); | ||
| } | ||
| } | ||
| }); | ||
| } |
There was a problem hiding this comment.
What symptoms do the changes in this PR fix?
There was a problem hiding this comment.
Race conditions of events coming in as the thread is being created async during a subsequent /sync response, now threads are always created and stored synchronously (so findEventById continue to function) then more data is fetched into them as soon as possible
Why?
There was a problem hiding this comment.
What bugs in the UI manifested before that spawned this change? Is it just a refactor after noticing the potential race?
There is no context around why/what besides the code itself.
I was curious because I saw this PR as a "What's new?" item when updating and checking whether this fixes this sort of problem, https://github.com/matrix-org/element-web-rageshakes/issues/12681
There was a problem hiding this comment.
There is no context around why/what besides the code itself.
Its in the backref'd PR
matrix-org/matrix-react-sdk#8448
element-hq/element-web#21627
I was curious because I saw as a "What's new?" item when updating and checking whether this fixes this sort of problem, https://github.com/matrix-org/element-web-rageshakes/issues/12681
Unlikely, that looks more like element-hq/element-web#21613 (comment)
There was a problem hiding this comment.
Its in the backref'd PR
matrix-org/matrix-react-sdk#8448
vector-im/element-web#21627
ohh, that's confusing just following the same name PR breadcrumbs in the activity log. I added those links to the PR description.
Thanks for the context 🙂
There was a problem hiding this comment.
Normally we only link from the downstream project upstream, given that js-sdk shouldn't be tailoring to a specific consumer
There was a problem hiding this comment.
That seems a bit backwards.
The usage of matrix-js-sdk is where new bugs are found and new usages are desired. Giving examples and explaining that these race conditions can cause reactions not to show on threaded messages because of xxx, is pretty relevant to the changes here.
I think even more context should be explained here besides linking to those issues btw. I don't know what the code is actually doing here but it could explain something like, "Instead of adding events directly to the timeline, we emit ThreadEvent.Update which clients can react to and refresh the timeline. This fixes the order so that whatever is not missing in a race when this happens."
* Live location sharing: handle encrypted messages in processBeaconEvents ([\matrix-org#2327](matrix-org#2327)). * Fix race conditions around threads ([\matrix-org#2331](matrix-org#2331)). Fixes element-hq/element-web#21627. * Ignore m.replace relations on state events, they're invalid ([\matrix-org#2306](matrix-org#2306)). Fixes element-hq/element-web#21851. * fix example in readme ([\matrix-org#2315](matrix-org#2315)). * Don't decrement the length count of a thread when root redacted ([\matrix-org#2314](matrix-org#2314)). * Prevent attempt to create thread with id "undefined" ([\matrix-org#2308](matrix-org#2308)). * Update threads handling for replies-to-thread-responses as per MSC update ([\matrix-org#2305](matrix-org#2305)). Fixes element-hq/element-web#19678.
Part of matrix-org/matrix-react-sdk#8448 which fixes element-hq/element-web#21627
Here's what your changelog entry will look like:
🐛 Bug Fixes