This came up now because Timeline uses a MappedList to map PendingEvents
to PendingEventEntries. In the map function, we setup links between
entries to support local echo for relations. When opening a timeline
that has unsent relations, the initial populating of the MappedList
will try to emit an update for the target entry in remoteEntries.
This all happens while the ListView of the timeline is calling subscribe
and all collections in the chain are populating themselves based on
their sources.
This usually entails calling subscribe on the source,
and now you are subscribed, iterate over the source (as you're not
allowed to query an unsubscribed observable collection, as it might not
be populated yet, and even if it did, it wouldn't be guaranteed to be
up to date as events aren't flowing yet).
So in this concrete example, TilesCollection hadn't populated its tiles
yet and when the update to the target of the unsent relation reached
TilesCollection, the tiles array was still null and it crashed.
I thought what would be the best way to fix this and have a solid model
for observable collections to ensure they are always compatible with
each other. I considered splitting up the subscription process in two
steps where you'd first populate the source and then explicitly start
events flowing.
I didn't go with this way because it's really only updates that
make sense to be emitted during setup.
A missed update wouldn't usually bring the collections out of sync
like a missed add or remove would. It would just mean the UI isn't
updated (or any subsequent filtered collections are not updated),
but this should be fine to ignore during setup, as you can rely
on the subscribing collections down the chain picking up the update
while populating. If we ever want to support add or remove events
during setup, we would have to explicitly support them, but for now
they are correct to throw.
So for now, just ignore update events that happen during setup
where needed.
turns out we do have to always check for replay attacks because
failing to decrypt doesn't prevent an item from being stored,
so if you reload and then load you might be decrypting it
for the first time
