- BREAKING: create `DatabaseApi.storeWellKnown` method
- BREAKING: create `DatabaseApi.getWellKnown` method
- add new getter `Client.wellKnown` containing cached `DiscoveryInformation`
- override `Client.homeserver` to invalidate `Client.wellKnown` in case the domain changed
- override `Client.getWellknown` to cache the resolved `DiscoveryInformation`
- add tests for well-known cache
Fixes: #1865
Signed-off-by: The one with the braid <info@braid.business>
Synapse includes the room in both sections if you have both an
invite->leave and a leave->invite transition in one sync response.
Transitions in the other order are only included once (in the leave
section) it seems, so this should work correctly in all cases.
Fixes https://github.com/famedly/product-management/issues/2283
This changes the behavior
when client init fails. It
no longer calls logout and does
only clear local data while
returning all available
information in a new
exception type so that the
SDK consumer can decide
to logout or try again to init
with these information. This
should make it much more rare
that users loose their sessions.
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.
You can either set them to private on the client or overwrite the
behaviour for that on each readMarker call. This also handles incoming
thread receipts and tries its best to figure out what is the latest
receipt. This however breaks the old m.receipt account data event.
- migrated to more useful MSC directory structure
- migrate Widgets API into new structure
- add recent emoji API into new structure
The recent emoji API is non-standard and should be compatible with Element.
Signed-off-by: Lanna Michalke <l.michalke@famedly.com>
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
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.
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.
RoomUpdate came from a time where we had no data model for
SyncUpdates but now we have and therefore this class is just
code duplication. This removes the class
and uses the SyncRoomUpdate class from
the package matrix_api_lite instead.
It needed a lot of refactoring at some places
where I also have removed some unnecessary null or type checks.
As it turns out, some of the code set the prev_batch for rooms too
early to an empty string. For synapse this means "request from the start",
for conduit it is just an error. This commit fixes that by never resolving
null --> empty string, but instead throw an error.
The one with the braid
Nicolas Werner
td
Krille
krille-chan
krille-chan
Krille
Philipp Grieshofer
Henri Carnot
Lanna Michalke
Sorunome