There are a few ways to fix this. We could skip events, where we don't
have the state in memory yet or always do a /profile request and cache
that.
I chose to go with loading the event from the database if necessary. If
we have a room in the db, we should have our memberevent in the db. In
some cases we might not (if the server thinks our memberevent is super
redundant), but I think the spec doesn't really allow that and it
doesn't happen in practice. And even if it would, we probably would want
our member event ASAP. And if we have no rooms, we fetch it from the
server as before instead of constructing a member with an MXID as the
username.
fixes https://gitlab.com/famedly/company/frontend/frontend-issue-inbox/-/issues/65
Reactions are triggering push
notifications and should therefore
be displayed as last events
in the room list of a client.
The body should just display
the reaction key.
This fixes that rooms with
new reactions can't set to
read.
FluffyBox behaves different on
web transactions which leads
to the result that _sortRooms()
is performed before the
rooms UI can be there. This
leads to an unsorted room list
on web.
I think the commit which broke it was this: e3bd0cf1 It makes sure that only important state events get cached and room member events are not important state events and so new invites have no room member events cached. It makes sense to also allow room member events here to always be cached as they are special typed.
The to_device queue was introduced to ensure integrity if e.g. the
server temporarily failed when attempting to send a to_device message.
If, for whatever reason, the server responds with a 4xx error, though,
then we want to ignore that to_device message from the queue and move on,
as that means that something different was fundamentally wrong. This
helps to fix the to_device queue clogging up, making clients incapable
of sending to_device events anymore, should such clogging happen.
If we dump all state events from sync into memory then we needlessly
clog up our memory, potentially running out of ram. This is useless
as when opening the timeline we post-load the unimportant state events
anyways. So, this PR makes sure that only the state events of post-loaded
rooms and important state events land in-memory when processing a sync
request.
We have disabled it by default to
prevent using workarounds as
long time solutions and to not
miss bugs. But in a federated
context we can not be sure that
we all Matrix clients are ever
bug free and we have now the
onEncryptionError Stream
anyway.
deviceKeysList.outdated is not nullable but we have seen this error
in production: `Failed assertion: boolean expression must not be null`
So this could either be a null safety bug in Dart or a result of
using unsound null safety. The extra equal check `== true` should
safe us here
This can improve the start-up time of apps.
The three big db reads on init are
loading account data, rooms and
device keys.
This makes it now possible to let
them run parallel
(while it may depend on platform
if this has any effect)
and the init() method can skip
awaiting them. They will
be at least awaited before handling
the first received sync.
So the app can already display the
room list before device keys are
loaded and request the first sync
from the server before anything
else is loaded from the DB.
Room states are ignored if the event with the same event ID
is already known in the database. But
because of the event is stored in the
database and after this
setState in the Room class is called,
an event is always "known" and
therefore auto updating was broken.
Just using the .init() method to wait for the client
to initialize is a more easy way than listen to onLoginStateChanged.
But by default it waits for the first sync.
This should be configurable.
Previously when using RoomUpdate in the constructor the notificationCount to update
was never null and set to 0 if it was missing. Now that we are
no longer using it, I forgot to
add the null fallback at this point.
This leads to serious crashes in the apps at runtime
and thats why I bump the version here as well!