Conversation
Contributor
Deploying with
|
| Status | Preview URL | Commit | Alias | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! | https://pr-778-sable.raspy-dream-bb1d.workers.dev | a37b32b | pr-778 |
Fri, 08 May 2026 21:47:26 GMT |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fixes the bug that occurs when a reply to a message that also has replies (so a message in the middle of a reply chain) has a thread started on that message causing a hang.
My shortcut introduced to improve loading speeds by bypassing the SDKs on-load thread single event spam created empty fake thread events whenever it was called. It assigned each of those as a thread root message, bypassing the SDKs various checks. As a result, when a thread was started involving those bypassed shells, uh, they didn't always get properly reloaded and had extraneous data causing infinite loops and whatnot.
Now, long story short, there's an extra method that actually checks for the thread root along with associated fixes to reduce rerenders and calculations and... well I tried a lot of random stuff, some works, some didn't, and to be totally honest I'm not 100% sure how all these changes work.
But hey it works! I think thread performance is still a little worse than the main timeline, not specifically related to this, but that's all noted and out of scope for this PR.
Type of change
Checklist:
AI disclosure:
AI was involved in the debugging stages to locate the issue and handled the test case updates.