Current behavior
The Tests - WebAssembly Skia stage intermittently fails every shard retry with:
Canary file not found. The app may not have started? Exiting.
##[error]Bash exited with code '1'.
followed by PublishTestResults failing with No test result files matching ...skia-browserwasm-runtime-tests-results.xml were found.
When this happens the job log contains zero HTTP requests to the python -m http.server that serves the app — Chrome starts (its dbus/gpu warnings appear) but never navigates to the URL it was given, so the app never boots and never writes the canary file.
Because build/test-scripts/wasm-run-skia-runtime-tests.sh only retries 5 times and each retry re-rolls the same dice, re-queueing the pipeline does not reliably clear it.
Root cause
google-chrome is launched without --no-first-run / --no-default-browser-check / --disable-search-engine-choice-screen, and without a pre-existing profile. On a CI agent the profile directory is brand new, so Chrome runs its first-run experience and discards the URL passed on the command line.
This is why the first launch in a job never produces a request: across the WASM runs of one build, every run that eventually passed shows exactly one Canary file not found. retrying... before succeeding (the second launch reuses the now-initialised profile and navigates in ~0.1s, writing the canary ~6s later). When the agent is slow enough that killall -9 lands before the profile is persisted, every one of the five retries repeats the first run and the stage fails permanently.
Reproduced locally, same fresh-profile condition, against a local http.server:
| Flags |
Result |
| none |
0 requests in 20 s — Chrome never navigated |
| --no-first-run --no-default-browser-check --disable-search-engine-choice-screen |
GET arrived in ~1 s |
Expected behavior
Chrome navigates to the runtime-tests URL on the first launch, the canary appears within seconds, and a WASM shard is not silently spending one of its five retries on Chrome's welcome screen.
How to reproduce
Observed on builds across several unrelated branches, e.g. PRs #24009, #24083, #24070, #24103, #24108 and #24072 — i.e. it is not specific to any one change.
Workaround
Re-queue the stage and hope Chrome persists its profile in time.
Environment
Azure Pipelines Linux agents, build/test-scripts/wasm-run-skia-runtime-tests.sh. The same script is present on master, feature/breakingchanges and release/stable/6.7.
Current behavior
The Tests - WebAssembly Skia stage intermittently fails every shard retry with:
followed by PublishTestResults failing with No test result files matching ...skia-browserwasm-runtime-tests-results.xml were found.
When this happens the job log contains zero HTTP requests to the python -m http.server that serves the app — Chrome starts (its dbus/gpu warnings appear) but never navigates to the URL it was given, so the app never boots and never writes the canary file.
Because build/test-scripts/wasm-run-skia-runtime-tests.sh only retries 5 times and each retry re-rolls the same dice, re-queueing the pipeline does not reliably clear it.
Root cause
google-chrome is launched without --no-first-run / --no-default-browser-check / --disable-search-engine-choice-screen, and without a pre-existing profile. On a CI agent the profile directory is brand new, so Chrome runs its first-run experience and discards the URL passed on the command line.
This is why the first launch in a job never produces a request: across the WASM runs of one build, every run that eventually passed shows exactly one Canary file not found. retrying... before succeeding (the second launch reuses the now-initialised profile and navigates in ~0.1s, writing the canary ~6s later). When the agent is slow enough that killall -9 lands before the profile is persisted, every one of the five retries repeats the first run and the stage fails permanently.
Reproduced locally, same fresh-profile condition, against a local http.server:
Expected behavior
Chrome navigates to the runtime-tests URL on the first launch, the canary appears within seconds, and a WASM shard is not silently spending one of its five retries on Chrome's welcome screen.
How to reproduce
Observed on builds across several unrelated branches, e.g. PRs #24009, #24083, #24070, #24103, #24108 and #24072 — i.e. it is not specific to any one change.
Workaround
Re-queue the stage and hope Chrome persists its profile in time.
Environment
Azure Pipelines Linux agents, build/test-scripts/wasm-run-skia-runtime-tests.sh. The same script is present on master, feature/breakingchanges and release/stable/6.7.