diff options
author | Alexey Rusakov <Kitsune-Ral@users.sf.net> | 2022-01-29 16:12:22 +0100 |
---|---|---|
committer | Alexey Rusakov <Kitsune-Ral@users.sf.net> | 2022-01-29 16:12:22 +0100 |
commit | 350f40d07943a32319182bac6a21adf456642075 (patch) | |
tree | e8d76faf1c708194bc002dd3177bff3722fd6db1 /lib/csapi/keys.h | |
parent | b39b70bf90d816377b2873a5c2506bd256c0a00e (diff) | |
download | libquotient-350f40d07943a32319182bac6a21adf456642075.tar.gz libquotient-350f40d07943a32319182bac6a21adf456642075.zip |
SyncData: expect self-contained /sync response
SyncData can load room objects out-of-line. This is only expected when
loading data from the cache (and since quite long ago, the cache always
saves room objects out of line, avoiding too large JSON payloads that
Qt parser chokes on). However, the code processed /sync response in
the same way; in particular, this meant that SyncData filled the vector
of unresolved room ids even when it came from /sync. SyncJob then looked
at this vector and entered an error state if it was not empty. Well,
payloads from the wire can be weird and it ultimately came to pass that
a homeserver returned a non-object against a given room key, triggering
the unresolved rooms branch in SyncJob - and stalling the whole sync
loop as a result (https://invent.kde.org/network/neochat/-/issues/500).
With this commit SyncData only fills unresolvedRoomIds when loading
rooms from the cache (with the implied fallback of discarding the cache
and loading from /sync anew instead). Respectively, SyncJob must never
end up with SyncData that has unresolved rooms (even if those occur
in the actual payload like in the mentioned issue, those rooms will be
completely empty instead); the added assertion only guards for internal
consistency.
Diffstat (limited to 'lib/csapi/keys.h')
0 files changed, 0 insertions, 0 deletions