fix: OIDC/SSO Token + Media issues

[Just-Insane]

Description

Three related bug fixes for media reliability.

1. Suppress unhandled promise rejections from useAsyncCallback

useAsyncCallback stored errors in AsyncStatus.Error state and then re-threw them. Fire-and-forget call sites (e.g. loadSrc() / loadThumbSrc()) had no .catch(), so every failure produced an "Uncaught (in promise)" console error — most visibly "Mismatched SHA-256 digest" from encrypted media decryption. The error is already surfaced via retry UI; the re-throw added nothing. Removed it and updated the test accordingly.

2. Wire OIDC token refresh through to the service worker

loginUtil.ts silently discarded refresh_token from the login response, so createClient was never given a tokenRefreshFunction. After an access token expired the SDK would stall and the service worker — which caches the token for authenticated media requests — would keep sending the old Bearer token, causing 401s on every media load.

• loginUtil.ts: capture refresh_token / expires_in_ms into the session object
• initMatrix.ts: when a refreshToken is present, pass tokenRefreshFunction to createClient; the function calls mx.refreshToken() and invokes an optional onTokenRefresh callback
• ClientRoot.tsx: supply the callback; it writes the new tokens to sessionsAtom and calls pushSessionToSW so the SW picks them up immediately

No-op when the server doesn't return a refresh token.

3. Retry authenticated media requests on 401 in the service worker

There is a timing window between when the SDK resolves a token refresh (and updates its own in-flight requests) and when the resulting pushSessionToSW setSession postMessage is processed by the SW. Media requests that land in this window carry the stale Bearer token and receive 401. Because browsers retry failed image/video loads automatically, this produced repeated 401 bursts for the same media IDs.

Added fetchMediaWithRetry() in sw.ts: on a 401 response it re-checks the in-memory sessions map (and preloadedSession fallback) for a fresher token for the same origin. If one is found, the request is retried once. Applied consistently across all four code paths in the fetch event handler. Zero overhead for non-401 responses.

Fixes #

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

AI disclosure:

• Partially AI assisted (clarify which code was AI assisted and briefly explain what it does).
• Fully AI generated (explain what all the generated code does in moderate detail).

Fix 1 removes throw e from useAsyncCallback's catch block and drops the now-unnecessary .catch(() => {}) in the test. Fix 2 reads refresh_token/expires_in_ms from the login response and stores them in the session; buildClient spreads { refreshToken, tokenRefreshFunction } into createClient options when a refresh token is present; the onTokenRefresh callback in ClientRoot updates sessionsAtom and calls pushSessionToSW with the new access token. Fix 3 adds fetchMediaWithRetry() to sw.ts — a thin wrapper around fetch() that on HTTP 401 re-checks the in-memory sessions map for a token that differs from the one just used, and if found retries the request once; covers the race window between SDK token refresh and SW setSession propagation.

[Copilot]

Pull request overview

This PR targets media reliability by addressing token refresh propagation and service-worker handling of authenticated media fetches, plus reducing noisy “Uncaught (in promise)” console errors in media-loading UI flows.

Changes:

• Adjust useAsyncCallback error handling behavior and update its tests.
• Persist OIDC refresh_token/expires_in_ms into session state and wire a tokenRefreshFunction into the Matrix client, propagating refreshed access tokens to the service worker.
• Add a SW media fetch wrapper that retries once on HTTP 401 using the latest in-memory/live session token.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/sw.ts	Adds fetchMediaWithRetry() and routes media fetch paths through it to mitigate 401s during token-refresh propagation races.
src/client/initMatrix.ts	Passes refresh-token options into createClient and plumbs an optional onTokenRefresh callback to propagate new tokens outward.
src/app/pages/client/ClientRoot.tsx	Supplies the onTokenRefresh callback to update sessions state and push updated tokens to the SW.
src/app/pages/auth/login/loginUtil.ts	Stores refresh_token and expires_in_ms into the session record on login.
src/app/hooks/useAsyncCallback.ts	Changes error handling in the async wrapper (no longer rejects on error) and documents rationale.
src/app/hooks/useAsyncCallback.test.tsx	Updates error test to no longer expect a rejected promise.
.changeset/fix-media-error-handling.md	Adds a patch changeset describing the combined fixes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Changing the catch path to resolve (returning undefined) instead of rejecting breaks existing call sites that rely on promise rejection to skip success handlers. For example, submit(...).then(onSave) patterns will now run onSave even when the async work failed, because the promise no longer rejects. Consider keeping rejection semantics (still throw/reject after setting Error state) while suppressing unhandled rejections by attaching an internal no-op .catch handler to the returned promise before returning it to callers (so ignored promises don’t log, but awaited/handled ones still reject).

[Copilot]

expires_in_ms is a number and could validly be 0; using a truthy check will drop the field when it’s 0. Prefer an explicit !== undefined/!= null check when copying expires_in_ms (and similarly for refresh_token if empty-string is a possible value) to avoid silently losing token-expiry metadata.

Suggested change

	...(loginRes.refresh_token && { refreshToken: loginRes.refresh_token }),
	...(loginRes.expires_in_ms && { expiresInMs: loginRes.expires_in_ms }),
	...(loginRes.refresh_token != null && { refreshToken: loginRes.refresh_token }),
	...(loginRes.expires_in_ms != null && { expiresInMs: loginRes.expires_in_ms }),

[Copilot]

res.expires_in_ms is numeric; using a truthy check will treat 0 as “absent” and return expiry: undefined. Prefer checking typeof res.expires_in_ms === 'number' (or != null) so an explicit 0ms expiry is handled consistently.

Suggested change

	expiry: res.expires_in_ms ? new Date(Date.now() + res.expires_in_ms) : undefined,
	expiry:
	typeof res.expires_in_ms === 'number'
	? new Date(Date.now() + res.expires_in_ms)
	: undefined,

[Copilot]

pushSessionToSW supports sending userId, and the SW persists userId to associate push notifications with an account. These calls omit userId, which can overwrite a previously stored SW session and clear its userId (since setSession stores userId: undefined when omitted). Pass activeSession.userId in both the initial push and the token-refresh push so the SW keeps a complete session record.

Suggested change

	pushSessionToSW(activeSession.baseUrl, newAccessToken);
	});
	loadedUserIdRef.current = activeSession.userId;
	pushSessionToSW(activeSession.baseUrl, activeSession.accessToken);
	pushSessionToSW(activeSession.baseUrl, newAccessToken, activeSession.userId);
	});
	loadedUserIdRef.current = activeSession.userId;
	pushSessionToSW(activeSession.baseUrl, activeSession.accessToken, activeSession.userId);

[Copilot]

This test now awaits result.current[1]() without asserting that the returned promise rejects on failure. If useAsyncCallback is intended to preserve “failure rejects” semantics (so callers’ .then success handlers don’t run on errors), this test should explicitly expect a rejection while still asserting state transitions to AsyncStatus.Error.

Suggested change

	await result.current[1]();
	await expect(result.current[1]()).rejects.toBe(boom);