Skip to content

VAST-84: Fix race condition in async initialization#84

Merged
privaloops merged 1 commit intodevelopfrom
fix/VAST-84-race-condition-async-init
Feb 24, 2026
Merged

VAST-84: Fix race condition in async initialization#84
privaloops merged 1 commit intodevelopfrom
fix/VAST-84-race-condition-async-init

Conversation

@privaloops
Copy link
Contributor

Summary

  • Remove const self = this pattern (workaround for Turbopack bundling issue, VAST-72)
  • Replace async IIFE with .then() to preserve lexical this in class context
  • Register event listeners before async VAST fetch to prevent race condition where readyforpreroll could fire before listeners were attached
  • Aligns VAST path with VMAP path which already registered listeners first

Context

Under Turbopack, this was lost inside the async IIFE (VAST-72). The const self = this workaround fixed that but masked a deeper issue: addEventsListeners() was called after the async fetch, meaning events emitted during the fetch were missed (VAST-84). This was also related to PLAYER-3648 where plugin re-instantiation caused tracking failures.

Test plan

  • Unit tests pass (28/28)
  • ESLint clean
  • Build (CJS + ESM) succeeds
  • E2E tests on CI
  • Manual validation with ARTE Video Player (sensitive: SST tracking)

…-84)

- Remove const self = this pattern that was a workaround for Turbopack (VAST-72)
- Replace async IIFE with .then() to preserve lexical this
- Call addEventsListeners() before handleVAST() to prevent race condition
  where readyforpreroll could fire before listeners were attached
@privaloops privaloops added this to the 1.6.0 milestone Feb 24, 2026
@privaloops privaloops merged commit cb9f3fd into develop Feb 24, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant