Calling `/versions` no longer works when the access token requires a refresh (via MAS).

[pixlwave]

We started noticing an issue recently on Element X (both platforms) which goes something along these lines:

• Launch the app when both the access token and the cached ServerInfo (which contains /versions data) have expired.
• The SDK attempts to make a /versions request.
• As of Upgrade Ruma #5789, Ruma now includes the access token on /versions meaning that the following error is returned
  • Api(Server(ClientApi(Error { status_code: 401, body: Standard { kind: UnknownToken { soft_logout: false }, message: "Token is not active" } })))
• The SDK sees that error and attempts to refresh the access token.
• Refreshing the access token via MAS requires knowledge of the authentication server so a get_authorization_server_metadata request is sent.
• A get_authorization_server_metadata request requires knowledge of the supported /versions in order to build the correct path.
• Bad things happen™️

In practice we've seen this manifest in 2 different ways:

• The session is restored and navigation throughout the app works, but the SDK only ever sends /versions requests no matter what you attempts to do.
• Whilst setting up the session, SyncServiceBuilder::finish throws the following error which (on EXI at least) we handle with a fatal error
  • Generic(msg: "the server returned an error: [401 / M_UNKNOWN_TOKEN] Token is not active", details: Optional("RoomList(SlidingSync(Http(Api(Server(ClientApi(Error { status_code: 401, body: Standard { kind: UnknownToken { soft_logout: false }, message: \"Token is not active\" } }))))))"))

[pixlwave]

A couple of potential thoughts we had on fixes:

• Never evict the ServerInfo from the cache, instead be proactive and regularly update its value.
  • This isn't a direct fix, but is how the older mobile SDKs used to handle caching.
• Somehow avoid including the access token on /versions requests that were triggered by anything related to auth (or at least just token refresh).

[poljar]

Correct me if I'm wrong, but it seems that option 1 is already the case:

matrix-rust-sdk/crates/matrix-sdk/src/client/mod.rs

Lines 2186 to 2198 in 9fff07d

	/// Empty the server version and unstable features cache.
	///
	/// Since the SDK caches server info (versions, unstable features,
	/// well-known etc), it's possible to have a stale entry in the cache. This
	/// functions makes it possible to force reset it.
	pub async fn reset_server_info(&self) -> Result<()> {
	// Empty the in-memory caches.
	let mut guard = self.inner.caches.server_info.write().await;
	guard.supported_versions = CachedValue::NotSet;
	// Empty the store cache.
	Ok(self.state_store().remove_kv_data(StateStoreDataKey::ServerInfo).await?)
	}

This function is never called by the SDK internally. So how did you end up without a version populated is a bit of a mystery.

Perhaps EX called this function.

Though this does mean that we can't really use option 1 unless we want to remove this public function or change it's behavior completely.

[pixlwave]

When loading the info from the caches this happens:

matrix-rust-sdk/crates/matrix-sdk-base/src/store/traits.rs

Lines 1061 to 1072 in 34d71b0

	/// Decode server info from this serializable struct.
	///
	/// May return `None` if the data is considered stale, after
	/// [`Self::STALE_THRESHOLD`] milliseconds since the last time we stored
	/// it.
	pub fn maybe_decode(&self) -> Option<Self> {
	if now_timestamp_ms() - self.last_fetch_ts >= Self::STALE_THRESHOLD {
	None
	} else {
	Some(self.clone())
	}
	}

I think that's the only mechanism in place to trigger a new /versions request (ignoring the manual reset above) so that the cache is kept up to date.

[poljar]

Oh, you're indeed right. Thanks.