Description

This is a very niche bug that appears when the dehydrated devices and refresh tokens are used on the server. I assume that dehydrated devices are usually enabled when the server supports e2e encrypted rooms.

The bug occurs after requesting to login using the login_token with refresh_token:true. Which responds with the access_token and the refresh_token created for the current device. Then anytime the existing dehydrated device gets re-hydrated, it gets the access_token from the device we logged in with but not its refresh_token. Therefore, the access_token stays valid (because it's moved to a valid device), but the refresh_token gets "invalidated" - so to say - since it's linked to a "deleted device" - the device_id that we logged in with.

P.S. I might be confusing the wordings for dehydrated and re-hydrated. Please correct me!

Steps to reproduce

1. Login using login token and set refresh token to true --> response: access_token and refresh_token specifically for the device.
2. Get the dehydrated devices, and re-hydrate with the current device data.
3. Refresh using the refresh token from step 1 --> throws 400 with "Login raced against device deletion"

Homeserver

another homeserver

Synapse Version

1.79

Installation Method

Other (please mention below)

Database

PostgreSQL, single

Workers

Multiple workers

Platform

K8s cluster using ananace chart.

Configuration

dehydrated_device (msc2697)

Relevant log output

/refresh -> {status_code: 400 message: "Login raced against device deletion"}

Anything else that would be useful to know?

✌️