fix: media playback failing due to expired urls

[abhinavkrin]

Proposed changes (including videos or screenshots)

Background

Audio/video files served from S3 use presigned URLs that expire after a configurable timespan. When a user leaves a room open past that window, the media element’s subsequent Range requests hit a stale URL, leading to silent playback failures.

---

Changes

1. useReloadOnError hook

   • Listens to play, stalled, and error events on media elements.
   • Tracks expiresAt timestamp returned by the uploads endpoint.
   • On trigger, checks if the URL has expired before attempting recovery.
   • If expired, fetches fresh redirectUrl and expires via an ?replyWithRedirectUrl=true query to the existing /uploads/:fileId endpoint.
   • Swaps the media’s src, calls .load(), seeks to last known currentTime, and resumes playback.

2. Uploads endpoint enhancement

   • Supports an replyWithRedirectUrl=true query param.
   • When present, returns JSON { redirectUrl, expires } instead of streaming or redirecting.
   • No changes to existing redirect or proxy behavior.

3. UI fallback styling

   • On recovery for video, preserves the video dimensions by copying element dimensions to have minimal UI lag.

4. These were the solutions considered.

   Strategy	Chosen	Rationale
   Reactive error events	❌	Too delayed; Safari compatibility issues.
   Watchdog timer to detect stalls	❌	False positives on slow networks.
   HEAD validation on src url on stalls	❌	Fails without CORS headers.
   Media Source Extensions	❌	Overly complex; CORS/storage overhead.
   Service Worker proxy	❌	HTTPS/PWA constraints; added complexity.
   Expiry-aware recovery	✅	Minimal complexity; leverages existing metadata; no CORS constraints.

Screen.Recording.2025-07-30.at.7.16.21.PM.mov

Issue(s)

Steps to test or reproduce

1. Set the upload provider to amazon s3 bucket and configure it.
2. Set the url expiry time to a lower value (10s) under the s3 configuration.
3. Send an audio/video message to a channel and wait for more than 10 seconds.
4. Play the media and check if the playback recovers after stalling due to url expiry.
5. Should test both video and audio.

Further comments

SUP-771

[dionisio-bot]

Looks like this PR is ready to merge! 🎉
If you have any trouble, please check the PR guidelines

[changeset-bot]

🦋 Changeset detected

Latest commit: 5950773

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 39 packages

Name	Type
@rocket.chat/meteor	Patch
@rocket.chat/core-typings	Patch
@rocket.chat/rest-typings	Patch
@rocket.chat/uikit-playground	Patch
@rocket.chat/api-client	Patch
@rocket.chat/apps	Patch
@rocket.chat/core-services	Patch
@rocket.chat/cron	Patch
@rocket.chat/ddp-client	Patch
@rocket.chat/freeswitch	Patch
@rocket.chat/fuselage-ui-kit	Patch
@rocket.chat/gazzodown	Patch
@rocket.chat/http-router	Patch
@rocket.chat/livechat	Patch
@rocket.chat/model-typings	Patch
@rocket.chat/ui-avatar	Patch
@rocket.chat/ui-client	Patch
@rocket.chat/ui-contexts	Patch
@rocket.chat/web-ui-registration	Patch
@rocket.chat/account-service	Patch
@rocket.chat/authorization-service	Patch
@rocket.chat/ddp-streamer	Patch
@rocket.chat/omnichannel-transcript	Patch
@rocket.chat/presence-service	Patch
@rocket.chat/queue-worker	Patch
@rocket.chat/stream-hub-service	Patch
@rocket.chat/license	Patch
@rocket.chat/omnichannel-services	Patch
@rocket.chat/pdf-worker	Patch
@rocket.chat/presence	Patch
rocketchat-services	Patch
@rocket.chat/models	Patch
@rocket.chat/network-broker	Patch
@rocket.chat/mock-providers	Patch
@rocket.chat/ui-video-conf	Patch
@rocket.chat/ui-voip	Patch
@rocket.chat/instance-status	Patch
@rocket.chat/omni-core	Patch
@rocket.chat/omni-core-ee	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

PR Preview Action v1.6.2
🚀 View preview at https://RocketChat.github.io/Rocket.Chat/pr-preview/pr-36622/
Built to branch gh-pages at 2025-08-14 12:47 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[codecov]

Codecov Report

❌ Patch coverage is 74.71264% with 44 lines in your changes missing coverage. Please review.
✅ Project coverage is 65.55%. Comparing base (fd32867) to head (5950773).
⚠️ Report is 2 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #36622      +/-   ##
===========================================
- Coverage    65.92%   65.55%   -0.38%     
===========================================
  Files         3258     3183      -75     
  Lines       109188   108160    -1028     
  Branches     20711    20436     -275     
===========================================
- Hits         71987    70902    -1085     
- Misses       34538    34672     +134     
+ Partials      2663     2586      -77     

Flag	Coverage Δ
e2e	55.56% <24.70%> (-1.62%)	⬇️
unit	71.41% <70.68%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[MarcosSpessatto]

Can we add a changeset?

[gabriellsh]

I noticed there are no tests, neither unit nor end-to-end, for both BE and FE. Do you plan on adding some?

During testing, I noticed that the first time I hit play, the video reloads, no matter if the URL is not expired yet.

I was thinking, since we're adding a way to get the URL anyway, why not do it always, instead of waiting for it to fail before we attempt a recovery? I think it would simplify the logic a lot. We just need to save the last expiry date, if any of the events are fired we just check if expiryDate < currentDate, and if that's true we fetch again. WDYT?

[abhinavkrin]

During testing, I noticed that the first time I hit play, the video reloads, no matter if the URL is not expired yet.
I was thinking, since we're adding a way to get the URL anyway, why not do it always, instead of waiting for it to fail before we attempt a recovery? I think it would simplify the logic a lot. We just need to save the last expiry date, if any of the events are fired we just check if expiryDate < currentDate, and if that's true we fetch again. WDYT?

Agreed, that will make the logic simpler. But as I looke at it again, I think we can prevent this initial fetch.
Since, this fetch is useless in case of Google Storage, Filesystem, and gridfs.
I have modified the code a little and prevented url recovery when the media is played for the first time.
Initially we will wait for the stalled or error events. Once we have an expiry value with us, then we start checking for expiry for the play event as well.

		if (firstRecoveryAttempted.current) {
			if (!expiresAt) {
				console.debug('No expiration time set, skipping recovery');
				isRecovering.current = false;
				return;
			}
		} else if (event.type === 'play') {
			// The user has initiated a playback for the first time, probably we should wait for the stalled or error event
			// the url may still be valid since we dont know the expiration time yet
			isRecovering.current = false;
			return;
		}

[abhinavkrin]

I noticed there are no tests, neither unit nor end-to-end, for both BE and FE. Do you plan on adding some?

I have added unit tests for the hook.

[gabriellsh]

FE OK!