* Do not assume that a relation lives in main timeline if we do not know its parent
* For pagination, partition relations with unknown parents into a separate bucket
And only add them to relation map, no timelines
* Make addLiveEvents async and have it fetch parent events of unknown relations to not insert into the wrong timeline
* Fix tests not awaiting addLIveEvents
* Fix handling of thread roots in eventShouldLiveIn
* Fix types
* Fix tests
* Fix import
* Stash thread ID of relations in unsigned to be stashed in sync accumulator
* Persist after processing
* Revert "Persist after processing"
This reverts commit 05ed6409b3.
* Update unsigned field name to match MSC4023
* Persist after processing to store thread id in unsigned sync accumulator
* Add test
* Fix replayEvents getting doubled up due to Thread::addEvents being called in createThread and separately
* Fix test
* Switch to using UnstableValue
* Add comment
* Iterate
* Fix an existing test for editing messages in threads
While attempting to test a new change, I discovered that the test
"should allow edits to be added to thread timeline" did not actually
fail if its assertions failed. Further, those assertions were incorrect.
So this change fixes the test to create the thread, wait for it to be
initialised, and then add events to it. This simplifies the flow and
ensures the test fails if something unexpected happens.
* Move editing test into thread.spec.ts
* Isolate Thread global modification in beforeAll()
* Delete unneeded setUnsigned call
* Use standard message-creation methods
* Rename event variables
* Rename sender->user
* Remove unneeded variables
* Extract distractions into functions
* Fetch edits for thread messages
Modifies fetchEditsWhereNeeded to allow edits of threaded messages. The
code before prevented any relations from fetching edits, but of course
events in threads are relations.
We definitely want thread messages to get their edits fetched, and I
assume this is working in the real code, probably because the event
being looked at is some kind of eventmapped thing that doesn't have
proper relations visible on it.
In tests, if we don't make this change, we can't see edits getting
fetched.
* Add a test for fetching edits on demand in a thread
This test demonstrates the current behaviour, which contains a bug - we
don't actually add the right event to the timeline.
* Fix bug where original event was inserted into timeline instead of the edit event
* Fix an existing test for editing messages in threads
While attempting to test a new change, I discovered that the test
"should allow edits to be added to thread timeline" did not actually
fail if its assertions failed. Further, those assertions were incorrect.
So this change fixes the test to create the thread, wait for it to be
initialised, and then add events to it. This simplifies the flow and
ensures the test fails if something unexpected happens.
* Move editing test into thread.spec.ts
* Isolate Thread global modification in beforeAll()
* Delete unneeded setUnsigned call
* Use standard message-creation methods
* Rename event variables
* Rename sender->user
* Remove unneeded variables
* Extract distractions into functions
* Fetch edits for thread messages
Modifies fetchEditsWhereNeeded to allow edits of threaded messages. The
code before prevented any relations from fetching edits, but of course
events in threads are relations.
We definitely want thread messages to get their edits fetched, and I
assume this is working in the real code, probably because the event
being looked at is some kind of eventmapped thing that doesn't have
proper relations visible on it.
In tests, if we don't make this change, we can't see edits getting
fetched.
* Add a test for fetching edits on demand in a thread
This test demonstrates the current behaviour, which contains a bug - we
don't actually add the right event to the timeline.
* Fix an existing test for editing messages in threads
While attempting to test a new change, I discovered that the test
"should allow edits to be added to thread timeline" did not actually
fail if its assertions failed. Further, those assertions were incorrect.
So this change fixes the test to create the thread, wait for it to be
initialised, and then add events to it. This simplifies the flow and
ensures the test fails if something unexpected happens.
* Move editing test into thread.spec.ts
* Isolate Thread global modification in beforeAll()
* Delete unneeded setUnsigned call
* Use standard message-creation methods
* Rename event variables
* Rename sender->user
* Remove unneeded variables
* Extract distractions into functions
* Add a test for creating local echo receipts in threads
* Only add local receipt if it's after existing receipt
* Refactor local receipt tests to be shorter
* Tests for local receipts where we DO have recursive relations support
* Fix an existing test for editing messages in threads
While attempting to test a new change, I discovered that the test
"should allow edits to be added to thread timeline" did not actually
fail if its assertions failed. Further, those assertions were incorrect.
So this change fixes the test to create the thread, wait for it to be
initialised, and then add events to it. This simplifies the flow and
ensures the test fails if something unexpected happens.
* Move editing test into thread.spec.ts
