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.
This changes the behavior
of the markdown method to
only convert linebreaks inside
of p blocks. I found no better
solution yet for the problem
as otherwise also lists
will have linebreaks between
the list items. Unfortunately
the default linebreak syntax
seems not to fulfill our needs.
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.
- store left rooms in archive during sync (as well as they are removed
on join already)
- refactor room archive code
- fix typo
Internal reference: SMC-385
Signed-off-by: The one with the braid <info@braid.business>
Removes two test cases in the markdown test which do not work anymore.
Reason for this is that just parsing a word inside of $$ word $$
katex is not valid anyway because katex is only made for mathematical
things. So the output is undefined behavior anyway.
At least in our CI this throws a null assertion error and since we
explicitly expect this to sometimes be null in our code, we should store
it as such.
If you create DM room, but the other party doesn't join it, they might
be unable to create a new DM using startDirectChat. Since creating a new
DM is pretty much the same as joining the invite, we try to join the
pending DM invite first and fall back to creating a new room if that
fails.
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.
It wasn't quite obvious that invites were always sorted at the top, if
you just looked at the sort function. This makes it more explicit and
also makes invites always sort before favourited rooms.