[MWPW-199606]Fix intermittent issue of experiment data not fetched for A/B testing

[Ruchika4]

Problem

A race condition existed between workflow-acrobat's page config initialization and Adobe Launch (_satellite) not being ready at page load. When the unity block initialized, ensurePageConfig was fired fire-and-forget, which fetched page config and immediately called window._satellite.track(...) to retrieve Target experiment data. Since _satellite loads asynchronously, this call would throw a TypeError if Launch hadn't initialized yet. The error was caught and swallowed, leaving experimentData permanently null for that session because pageConfigFetched = true was already set, preventing any retry when the user actually uploaded a file.

Changes

unitylibs/utils/experiment-provider.js

• Added waitForSatellite() polls window._satellite every 100ms (up to 5 seconds) before invoking _satellite.track(...)
• Resolves immediately if _satellite is already present, rejects with a clear error on timeout
• Handles the common case where Launch initializes within a few seconds of page load

unitylibs/core/workflow/workflow-acrobat/action-binder.js

• Refactored ensurePageConfig to handle the edge case where _satellite takes longer than 5 seconds or fails for other reasons
• On getExperimentData failure: reset pageConfigFetched = false and pageConfigPromise = null so the existing || this.ensurePageConfig() guard in handleFileUpload naturally triggers a fresh attempt when the user uploads
• Added const isRetry = !!this.pageConfigLocation to detect first attempt vs user-triggered retry error is only dispatched to Splunk on retry, suppressing noise from the recoverable first-attempt failure
• fetchPageConfig catches all errors internally and always returns {}, so the catch block in ensurePageConfig is only ever reached via getExperimentData failure. Error is only dispatched to Splunk on retry (isRetry) since the first attempt failure is expected _satellite may not be loaded yet at page load. Flags are reset on failure to allow ensurePageConfig to be retried naturally when the user uploads a file.

test/utils/experiment-provider.test.js / test/core/workflow/workflow-acrobat/action-binder.test.js

• Added 9 unit tests covering waitForSatellite polling and timeout, ensurePageConfig guard, flag reset without Splunk dispatch on first failure, flag reset with Splunk dispatch on retry, and success paths via both pageConfig.config.target and targetCfg.experimentationOn

Behavior After Fix

Scenario	Outcome
_satellite ready before page config completes	Experiment data fetched at page load, no retry needed
_satellite not ready within 5s	Silent failure at page load, retry triggered automatically when user uploads
Retry also fails	Error dispatched to Splunk, resets again for next upload attempt

Test plan

• Verify experiment data is correctly fetched on pages where _satellite loads before user interaction (happy path)
• Verify no visible error toast appears to users when experiment data fetch fails at page load
• Verify file upload works correctly when _satellite is delayed past the 5s timeout
• Verify warn_fetch_experiment Splunk entry is logged only on retry failure, not on initial page load failure

Resolves: MWPW-199606

Test URLs:

• Before: https://main--da-dc--adobecom.aem.live/acrobat/online/split-pdf?unitylibs=stage
• After: https://main--da-dc--adobecom.aem.live/acrobat/online/split-pdf?unitylibs=page-config

[aem-code-sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch and validate page speed.
In case there are problems, just click a checkbox below to rerun the respective action.

• Re-run all PSI checks
• Re-run failed PSI checks
• Re-sync branch

Commits

• 8cb7e85 ✅ (latest)
• 0ea8ee3 ✅
• 25dc828 ✅
• 2086d15 ✅
• 17cf016 ✅
• 35aab6c ✅
• e0cc669 ✅
• a74aa88 ✅

[vipu0303]

do we need to dispatch the error toast in both the cases?

[Ruchika4]

Good catch, Vipul. I realized that fetchPageConfig catches all errors internally and always returns {} (https://github.com/adobecom/unity/blob/stage/unitylibs/scripts/utils.js#L351), so the catch block in ensurePageConfig is only ever reached via getExperimentData failure. The isRetry check is to make sure we log the error only when even after the retry target data could not be fetched since at first attempt at page load there is a chance that launch is not ready and also avoid duplicate error messages to be logged. I have removed the check of fetchpageConfig from catch and now logging error only for isRetry.