This should highly increase the
performance as right now for every sync
ALL inbound group sessions are loaded
from the database and checked if
they need an upload. So if a user
has 10k stored sessions locally, this
would probably let the whole application
lag a lot. This stores the sessions which
need upload in a different table now,
similar how we do this with the to
device queue
dynamic.copy returned a type
error so I reverted the previous
change of the copyMap
method to an extension. Also
I found out that we have used
two copyMap methods in the
SDK which did exactly the same.
I deleted the old one and
changed the tests.
BREAKING CHANGE: This replaces the old dehydrated devices
implementation, since there is no way to query what is supported easily
and supporting both would be complicated.
fixes https://github.com/famedly/matrix-dart-sdk/issues/1579
There were several issues here. Key uploads in general failed, because
the await caused a Future<dynamic> to be returned, which failed type
checking.
But also we never unset our future, which was used for the online key
backup uploads, which meant we would very quickly stop uploading any
keys at all.
BREAKING CHANGE: This changes the runInRoot method to not return a
future. As a user, if you need the result of an async computation passed
to runInRoot, please await it directly. Also the KeyVerification start
and a few call methods now return a future.
This does make the reset take longer on big accounts, but otherwise
users might sign out before the keys are uploaded, which makes the reset
more destructive than necessary. In the common case of not having any
keys it shouldn't make a difference.
Otherwise it would be possible, that we haven't loaded account data, so
we return that cross-signing is disabled and then we load it and return
a different result. Might fix the sentry issue for that.
This fixes a bug that the
last message was sent
incorrectly when a session
key received for example
from the key backup. It may
fix several issues like the
last message is set as a
very old one or the last
message is not decrypted.
Usually we store the keys we want to upload first, then upload them,
then store, that we uploaded them. So that should be fool proof.
But.
In some cases the filesyste lies to us and the database change isn't
actually persisted yet. That can happen when someone turns of their
phone aprubtly for example. In that case we generate new OTKs with the
same id. Uploading that will fail, since they already exist server side.
We can work around that by manually claiming them and removing them
locally.
Krille
krille-chan
td
krille-chan
Krille
Nicolas Werner
Malin Errenst
Reza
The one with the braid
TheOneWithTheBraid