[$250] Chat - The video doesn't load after disabling and re-enabling network

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.83-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: EDGEhttps://github.com/Expensify/Expensify/issues/613034
Email or phone of affected tester (no customers): undefined
Issue reported by: Applause Internal Team

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Go to your workspace chat.
3. send a short video.
4. Start playing the video
5. Open Chrome Devtools
6. Go to Network.
7. Disable the network.
8. Wait for 10 seconds.
9. Re-enable the network.
10. Play the video

Expected Result:

The video starts loading and continues to play after re-enabling the network.

Actual Result:

The video doesn't start to load again after re-enabling the network.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7136013_1776878147318.2026-04-22_18-56-37.mp4

Attachment:

Bug7136013_1779836818201.1995_Flashback__First-time_PC_user_can_t_work_computer.1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022059651054128997025
• Upwork Job ID: 2059651054128997025
• Last Price Increase: 2026-05-27

[MelvinBot]

Proposal

What is the root cause of that problem?

The onReconnect handler in BaseVideoPlayer.tsx:110-117 only reloads the video when currentTime <= 0 && hasError:

useNetwork({
    onReconnect: () => {
        if (!(currentTime <= 0 && hasError)) {
            return;
        }
        videoPlayerRef.current.replaceAsync(sourceURL);
    },
});

When a video is already playing and the network drops, here's what happens:

1. The video was playing, so currentTime > 0.
2. After 7 seconds offline, the effect at line 132-137 clears the video source via replaceAsync('') to stop infinite loading.
3. When the network reconnects, onReconnect fires — but the condition fails because currentTime > 0, so the video source is never restored.

The reconnect handler was written to cover videos that fail on initial load (currentTime 0 + error status), but it doesn't cover videos that were mid-playback when the network dropped and had their source cleared by the offline-threshold logic.

What changes do you think we should make in order to solve the problem?

Broaden the onReconnect condition in BaseVideoPlayer.tsx to also restore the video source when it was cleared due to being offline. The simplest approach: also call replaceAsync(sourceURL) when isVideoOffline was true (or equivalently, when the current source is empty/cleared). The existing condition for currentTime <= 0 && hasError should remain as-is to continue covering the initial-load failure case.

What alternative solutions did you explore? (Optional)

An alternative would be adding an onReconnect effect tied to the isVideoOffline state (a separate useEffect that watches isVideoOffline transitioning from true to false and calls replaceAsync(sourceURL)). This would work but adds a separate code path for what is conceptually the same recovery action. Consolidating the logic in the existing onReconnect handler is cleaner.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-27 15:02:17 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user starts playing a video in chat, then disables their network mid-playback for ~10s and re-enables it, the video never resumes loading. Clicking play has no effect and the video stays blank instead of buffering and continuing playback as expected.

What is the root cause of that problem?

The bug lives in BaseVideoPlayer.tsx and is caused by an interaction between two effects that manage the expo-video player's source during offline transitions. While the user is offline, the player's HTML5 <video> enters the waiting state because the browser can no longer fetch bytes, which causes expo-video's web shim to emit statusChange with status: 'loading' (see the onwaiting handler that sets this.status = 'loading', never 'error', in node_modules/expo-video/src/VideoPlayer.web.tsx lines 448-451). After OFFLINE_THRESHOLD (7s) of being offline the effect at lines 119-130 flips isVideoOffline to true, and the effect at lines 132-137 then calls videoPlayerRef.current.replaceAsync(''). On web that maps to replace('') which executes video.removeAttribute('src') + video.load() (see node_modules/expo-video/src/VideoPlayer.web.tsx lines 298-315), wiping the src from the underlying <video> element entirely.

When the network comes back, isOffline flips to false and the onReconnect callback registered at lines 110-117 runs. That callback is supposed to re-attach the source, but it is gated by if (!(currentTime <= 0 && hasError)) return; — it only re-loads when the player was at the very start of the video AND in error state.

App/src/components/VideoPlayer/BaseVideoPlayer.tsx

Lines 110 to 117 in 0b21f63

	useNetwork({
	onReconnect: () => {
	if (!(currentTime <= 0 && hasError)) {
	return;
	}
	videoPlayerRef.current.replaceAsync(sourceURL);
	},
	});

In this repro neither condition holds. The user had already played the video so the useEvent cache for timeUpdate still holds the last currentTime > 0 emitted before the stall (no further timeUpdate events fire after replaceAsync('') pauses the element). And hasError is false because a network stall produces onwaiting not onerror, so status is 'loading' rather than 'error'. The guard short-circuits, the source is never restored, and the user is left with a <video> whose src was removed by the offline cleanup but whose React-side state still believes there is a valid source — clicking play does nothing because the underlying element has nothing to load.

What changes do you think we should make in order to solve the problem?

Fix the onReconnect guard at lines 110-117 of BaseVideoPlayer.tsx so it also reloads the source whenever the offline cleanup actually wiped it. The cleanest signal is the same condition that triggered the wipe in the first place: the prior offline effect ran replaceAsync('') only when isVideoOffline && isLoading && isOffline was true. So we just need to remember whether that wipe happened (e.g. a wasSourceClearedRef = useRef(false) set to true inside the effect at lines 132-137 and reset on a successful reload) and reload in onReconnect whenever wasSourceClearedRef.current is true — independent of currentTime and hasError.

In the reload path we should call videoPlayerRef.current.replaceAsync(sourceURL) (existing behaviour) and additionally restore playback position by setting videoPlayerRef.current.currentTime = savedCurrentTimeRef.current after the replace resolves, since savedCurrentTimeRef already tracks the last currentTime > 0 (lines 313-318) and replaceAsync resets the element to time 0. The existing narrower path — reloading from an error state at the start — should be preserved by OR-ing the new condition with the existing one, so videos that genuinely errored at the start still recover. This keeps the fix local to the component (no changes to shared utilities), doesn't touch expo-video, and matches the precise Onyx-driven state transition (isOffline true → false) instead of guessing at signals like hasError.

What alternative solutions did you explore? (Optional)

We considered remounting the player via a key prop tied to a reconnect counter, which would force a full re-mount on every reconnect. We rejected it because remounting destroys the useVideoPlayer instance, breaks the mountedVideoPlayersRef/shared-element bookkeeping used by the playback context, and would lose savedCurrentTimeRef, dropping the user back to time 0 instead of resuming. We also considered removing the replaceAsync('') cleanup at lines 132-137 entirely, but that effect exists to free the offline-stalled element while the user sits on a chat for minutes; removing it would regress that scenario. Tracking whether the wipe happened and reversing it on reconnect is the minimum-surface change.

[yusufdeveloper2903]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On web, when a video playing in chat is interrupted by a network drop of more than ~7 seconds and the network is then restored, the video stays unloaded — pressing Play does nothing, no network request is made to fetch the video again.

What is the root cause of that problem?

The reconnect handler in BaseVideoPlayer.tsx gates source restoration on the wrong status:

useNetwork({
    onReconnect: () => {
        if (!(currentTime <= 0 && hasError)) {
            return;
        }
        videoPlayerRef.current.replaceAsync(sourceURL);
    },
});

A second effect a few lines below (L132-L137) deliberately unloads the source after the user has been offline for CONST.VIDEO_PLAYER.OFFLINE_THRESHOLD (7 s) and the player is still loading:

useEffect(() => {
    if (!(isVideoOffline && isLoading && isOffline)) {
        return;
    }
    videoPlayerRef.current.replaceAsync('');
}, [isLoading, isVideoOffline, isOffline]);

Trace with the repro values (play → offline 10 s → online):

1. t ≈ 0: status readyToPlay, currentTime > 0.
2. Network drops. Buffer drains → status loading, isOffline = true.
3. After 7 s the threshold timer sets isVideoOffline = true → the L132-L137 effect fires → replaceAsync(''). The source is now empty, currentTime → 0, and status goes to idle/loading — not error, because an empty source is not an error condition in expo-video. So hasError = false.
4. Network is restored. useNetwork's reconnect effect fires the latest onReconnect closure (useNetwork.ts L20-L28) before the L119-L130 effect runs to flip isVideoOffline back.
5. Inside onReconnect: currentTime <= 0 && hasError → true && false → false → early-return. sourceURL is never restored. The video stays empty; pressing Play has no source to play.

This was a regression introduced in commit 83e5af0 ("use onReconnect, use fullscreenOptions") inside PR #75270 (expo-av → expo-video migration). The original code used a useEffect keyed on shouldShowErrorIndicator = hasError && !isVideoOffline, which fired when isVideoOffline flipped back to false after reconnect, covering this path. The rewrite collapsed it to an onReconnect callback but only kept the hasError branch, dropping the offline-clear branch.

What changes do you think we should make in order to solve the problem?

Extend the onReconnect gate to also restore the source when the offline-threshold effect cleared it (i.e. isVideoOffline was true at reconnect time):

 useNetwork({
     onReconnect: () => {
-        if (!(currentTime <= 0 && hasError)) {
+        if (!(currentTime <= 0 && (hasError || isVideoOffline))) {
             return;
         }
         videoPlayerRef.current.replaceAsync(sourceURL);
     },
 });

Why this is correct and bounded:

• useNetwork re-binds callback.current on every render (useNetwork.ts L11-L14), so the closure inside onReconnect reads the freshly rendered values. At the moment the reconnect effect fires, isOffline has just flipped to false, but the L119-L130 effect that clears isVideoOffline has not yet run — so isVideoOffline is exactly true iff the L132-L137 effect cleared the source during the outage. That is the precise condition under which we must call replaceAsync(sourceURL).
• Outages shorter than OFFLINE_THRESHOLD (7 s) never set isVideoOffline, never clear the source, and the new branch evaluates to false for them — expo-video resumes on its own, unchanged.
• The existing hasError branch is preserved verbatim, so the codec/404 error case is unaffected.
• One file, one line. No changes to useNetwork, the offline-threshold effect, CONST.VIDEO_PLAYER.OFFLINE_THRESHOLD, or the VideoErrorIndicator/AttachmentOfflineIndicator paths.

Platforms: web (issue reproduces on Windows/Chrome). Native expo-video follows the same logic; the fix applies there too with no native-only deviation.

What alternative solutions did you explore? (Please describe them and explain why they were not selected)

1. Track the clear with a ref (wasSourceClearedRef.current = true inside the L132-L137 effect, reset to false after the reconnect replaceAsync). Rejected because isVideoOffline already encodes "the threshold effect ran during this outage" and is in scope — adding a parallel ref is duplicate bookkeeping that would drift if the threshold effect's deps ever change.

2. Always call replaceAsync(sourceURL) on reconnect. Rejected because for short blips (< 7 s) the source was never cleared, the player is mid-buffer, and forcing a re-load would re-trigger the auth-token fetch (addEncryptedAuthTokenToURL) and reset the playback position the user already saw — strictly worse than today's behavior.

3. Revert to the original useEffect keyed on shouldShowErrorIndicator && currentTime <= 0. Rejected because the onReconnect shape is the intended new API and is exercised by other paths in PR Expo-av to expo-video migration after revert #75270; the minimal local fix to the gate keeps the migration intact while restoring the dropped branch.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022059651054128997025

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Web (Chrome), when a video is playing and the network is disabled for more than 7 seconds and then re-enabled, the video does not start loading again and never resumes. Expected: after the network is restored, the video should reload and continue playing.

What is the root cause of that problem?

In src/components/VideoPlayer/BaseVideoPlayer.tsx, once the connection is offline past CONST.VIDEO_PLAYER.OFFLINE_THRESHOLD, the effect at lines 132-137 resets the player source with videoPlayerRef.current.replaceAsync(''). The only recovery path is the onReconnect handler at lines 110-117, which restores the source via replaceAsync(sourceURL) only when currentTime <= 0 && hasError. For a video that had already started playing, currentTime is greater than 0 (and the status is loading/idle, not error, after the source was cleared), so the guard short-circuits and the cleared source is never restored — leaving the video permanently blank.

What changes do you think we should make in order to solve the problem?

1. In src/components/VideoPlayer/BaseVideoPlayer.tsx (lines 110-117), broaden the onReconnect recovery condition so it also restores the source when it was cleared while offline — e.g. trigger replaceAsync(sourceURL) when isVideoOffline is true (source was reset by the lines 132-137 effect), in addition to the existing currentTime <= 0 && hasError case, rather than returning early.
2. After restoring the source on reconnect, seek back to savedCurrentTimeRef.current (already tracked at lines 313-318) so playback resumes from where it stopped instead of restarting at 0.
3. Verify the reset effect at lines 132-137 and the new recovery condition use consistent state so the source is always re-populated once isOffline clears and isVideoOffline is reset to false (lines 119-130).

What alternative solutions did you explore? (Optional)

Instead of clearing the source to '' while offline (lines 132-137), keep the source intact and rely on the player's native retry on reconnect; rejected as a larger behavioral change to the offline-indicator handling.

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[KJ21-ENG]

Replaces my earlier proposal - ProposalPolice withdrew the posted body. Layer 2 confirms the BaseVideoPlayer source-clear/reconnect bug, and this cleaned body narrows the fix to an explicit offline-clear flag plus a no-progress guard.

Proposal

Please re-state the problem that we are trying to solve in this issue.

On web, a chat video attachment can get stuck after the browser network is disabled and then re-enabled. After the user starts the video, waits offline long enough for the video offline handling to run, and comes back online, pressing play does not make the video request load again.

What is the root cause of that problem?

Chat video attachments render through VideoRenderer -> VideoPlayerPreview -> VideoPlayer -> BaseVideoPlayer. In BaseVideoPlayer, the expo-video player is initialized with one computed sourceURL.

The offline handling clears that source destructively. Once isOffline has been true for CONST.VIDEO_PLAYER.OFFLINE_THRESHOLD, the offline effect marks the video offline, and the next effect calls videoPlayerRef.current.replaceAsync('') when the player is still loading:

App/src/components/VideoPlayer/BaseVideoPlayer.tsx

Lines 119 to 137 in 8c3826c

	useEffect(() => {
	if (!isOffline) {
	setIsVideoOffline(false);
	return;
	}
	const timer = setTimeout(() => {
	setIsVideoOffline(true);
	}, CONST.VIDEO_PLAYER.OFFLINE_THRESHOLD);
	return () => clearTimeout(timer);
	}, [isOffline]);
	useEffect(() => {
	if (!(isVideoOffline && isLoading && isOffline)) {
	return;
	}
	videoPlayerRef.current.replaceAsync('');
	}, [isLoading, isVideoOffline, isOffline]);

On web, expo-video maps that empty replacement to removing the underlying <video> source and loading the empty element. So after the 10 second offline wait in the repro, the player can be left with no URL.

The reconnect handler does not restore the URL in that state. It only retries when the player is both at the beginning and in error:

App/src/components/VideoPlayer/BaseVideoPlayer.tsx

Lines 110 to 116 in 8c3826c

	useNetwork({
	onReconnect: () => {
	if (!(currentTime <= 0 && hasError)) {
	return;
	}
	videoPlayerRef.current.replaceAsync(sourceURL);
	},

That guard was written for an initial-load failure, not for a video that already started and then had its source intentionally cleared while offline. In the reported flow, currentTime can already be greater than 0, and the empty-source state does not need to surface as status === 'error'; it can remain loading/empty. The reconnect callback returns early, the source stays empty, and play has no URL to load.

What changes do you think we should make in order to solve the problem?

Update only src/components/VideoPlayer/BaseVideoPlayer.tsx.

Add a ref such as didClearSourceForOfflineRef near the other player refs. Before the offline effect calls replaceAsync(''), set that ref to true and keep the current playback position in savedCurrentTimeRef when available.

Then update the useNetwork({onReconnect}) callback so reconnect restores sourceURL whenever didClearSourceForOfflineRef.current is true, regardless of currentTime or hasError. Reset the ref after scheduling the restore. Keep the existing currentTime <= 0 && hasError retry path for the initial-load error case, but treat the offline-cleared-source case as its own explicit recovery branch so unsupported media errors are not retried forever.

Also tighten the destructive offline clear so it only removes the source when there is no usable playback progress, matching the existing offline indicator condition:

const hasNoBufferedProgress = currentTime + bufferedPosition <= 0;

Only call replaceAsync('') when isVideoOffline && isLoading && isOffline && hasNoBufferedProgress. That prevents us from throwing away an already-started or buffered video. If the source was intentionally emptied for a no-progress load, reconnect puts the original sourceURL back and Chrome can issue the media request again. If we restore after a non-zero position, seek back to savedCurrentTimeRef.current once the source is ready.

Regression coverage should mock expo-video and network state for three cases: confirmed offline/loading with no progress clears the source and records the offline clear; reconnect after that clear restores sourceURL even when hasError is false; confirmed offline/loading with currentTime + bufferedPosition > 0 does not clear the source.

What alternative solutions did you explore? (Optional)

Removing the offline replaceAsync('') call entirely would avoid this empty-source state, but it would also change the existing sustained-offline loading behavior. Retrying every reconnect for any video error is broader than needed and can keep retrying unsupported media. Remounting VideoPlayer with a reconnect key would also be heavier than necessary and risks disrupting the shared video player element used between previews and attachment routes. Tracking and reversing the specific offline source clear keeps the fix local to the failure mode.