Skip to content

Fix: Swallow AbortError from interrupted video play() - #365

Draft
posthog-eu[bot] wants to merge 1 commit into
mainfrom
posthog-self-driving/fixvideo-swallow-aborterror-from-ced667
Draft

posthog-eu[bot] wants to merge 1 commit into
mainfrom
posthog-self-driving/fixvideo-swallow-aborterror-from-ced667

Conversation

@posthog-eu

@posthog-eu posthog-eu Bot commented Sep 11, 2026

Copy link
Copy Markdown

Problem

  • On one production renderer session, media playback logged 9 phantom exceptions that error tracking recorded as unhandled crashes — two false issues, one noisy (8 hits in ~90 seconds).
  • Users are not affected: the video follows the shared playback state either way. The cost is noise that can bury a real renderer failure on a low-volume project.
  • Root cause: the renderer calls HTMLVideoElement.play() imperatively while react-player also drives the same element through playing={isPlaying}. A pause() or a new source load aborts the pending play, which rejects with DOMException: AbortError. The returned promise was not handled, so each rejection became an unhandled rejection captured as handled: false.

Changes

  • Guard the imperative play() in packages/video/src/client/VideoPlayer/VideoPlayer.tsx: attach a catch that ignores AbortError and rethrows any other error, so genuine media failures still surface.
  • No behavior change for users.

Scope note

  • The report also named plugins/video-player/view/Remote/VideoCard.tsx:80 for the same guard. That line calls videoControls.play(), which only mutates shared valtio state and returns void — it never touches a media element and cannot produce this rejection. The two error-tracking issues are AbortErrors from a media play(), and the only imperative media play() in the codebase is the one fixed here. So no change is needed at that call site.

Testing

  • Dependencies are not installed in this environment (node_modules absent), so lint, typecheck, and build were not run here. The change is a single catch on an existing call; please let CI verify.

Created with PostHog Desktop from this inbox report.

The renderer's imperative HTMLVideoElement.play() in VideoPlayer runs while
react-player also drives the same element through the `playing` prop. A pause
or a new source load can abort the pending play, which rejects with a
DOMException AbortError. The call did not handle the returned promise, so each
rejection became an unhandled rejection that exception autocapture recorded as
a false error tracking issue.

Attach a catch that ignores AbortError and rethrows any other error so real
media failures still surface. The video keeps following the shared playback
state, so there is no user-visible change.

Generated-By: PostHog Desktop
Task-Id: 40f0602d-da23-48e6-9a22-b655112375ce
@github-actions

Copy link
Copy Markdown
Contributor


Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.


I have read the CLA Document and I hereby sign the CLA


You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants