mirror of
https://github.com/matrix-org/matrix-rust-sdk.git
synced 2026-04-27 02:31:15 -04:00
When using the same pattern of `client.register(); client.login_*` that is used by tests in [our Acter app, strangely showed that more than one device/session had been opened](https://github.com/acterglobal/a3/issues/938). Turns out, if the server is set up for it, according [to the spec](https://spec.matrix.org/v1.8/client-server-api/#post_matrixclientv3register) registration _is_ already a login and both device id and access token will be returned ... which are then straight-up ignored by the matrix-sdk Client and without any way of setting it from the outside, one _must_ login again, creating a second unnecessary device/session. This PR adds an integration test case that checks that upon the minimal registration-login-flow only one device/session is found (as is to be expected from the outside), surfacing the error. It also contains a "somewhat fix" (as we need this in the app right now), but as it a) changes the behavior of the current API and b) isn't fully implementing the encryption-bootstrapping-pattern (and thus fails a different test), I'd leave it open to discussion whether that was appropriate way to go. --- * Test showing registration-login-pattern leads to too many devices * Fix too-many-devices-bug * Do not panic on failure to set session, refactor and add docs * refactor bootstrap crosssinging * Fixup * Use new post_login_cross_signing feature from Oidc, too * unwrap at construction for less verbose code * remove comment from test * make new fn pub(crate) to fix build
Matrix SDK integration test
Requirements
This requires a synapse backend with a ci patched configuration. You can easily get
it up and running with docker-compose via:
docker-compose -f assets/docker-compose.yml up -d
docker-compose -f assets/docker-compose.yml logs --tail 100 -f
Patches
You can see the patches we do to configuration (namely activate registration and
resetting rate limits), check out what assets/ci-start.sh changes.
Running
The integration tests can be run with cargo test or cargo nextest run.
The integration tests expect the environment variables HOMESERVER_URL to be the HTTP URL to
access the synapse server and HOMESERVER_DOMAIN to be set to the domain configured in
that server. If you are using the provided docker-compose, the default will be fine.
Maintenance
To drop the database of your docker-compose run:
docker-compose -f assets/docker-compose.yml stop
rm -rf ./assets/data