CI DIAGNOSTIC, do not merge: what the cloud returns to the runner - #25
Closed
jwrosewell wants to merge 3 commits into
Closed
CI DIAGNOSTIC, do not merge: what the cloud returns to the runner#25jwrosewell wants to merge 3 commits into
jwrosewell wants to merge 3 commits into
Conversation
SessionStorageCache_Chrome fails on ubuntu with "the first page must call the json endpoint at least once", while the same suite at the same commit, the same resource key and the same branch pass that assertion on a workstation. The client only posts when the served payload carries a JavaScript property with a body to run, so the question is what the cloud returns to a runner rather than anything in this repository. This prints the Chrome and ChromeDriver versions, then asks the running example for the include three ways, being a plain Chrome user agent, a HeadlessChrome user agent with no client hints, and a HeadlessChrome user agent with the client hints a real browser sends, and reports how many runnable JavaScript bodies come back for each. On a workstation the first and third return three and the second returns none, so if the runner differs the difference will show here. Branched from main rather than from either open pull request, so the run also shows whether main alone fails. Temporary. Remove this block once it has answered the question, which is tracked in issue 24. No resource key is printed, because the key stays inside the example rather than in the requests this makes.
The first diagnostic showed the cloud returns three runnable JavaScript bodies to the runner for a plain Chrome user agent and for a HeadlessChrome user agent carrying client hints, so the payload is not being withheld and the earlier theory about the user agent is wrong. The client still makes no post, so the next thing to see is what the browser itself receives and does. This drives real Chrome through a small proxy that keeps the include it forwarded, then prints the page state, the device id rendered, every request the browser made, and how many runnable JavaScript bodies the delivered include carried. On a workstation it prints one post and three runnable bodies, so a runner that prints none or zero says where the difference is. Temporary, alongside the rest of the block, and tracked in issue 24.
The browser leg on the runner rendered a device id but received an include carrying no JavaScript to run, so it never posted. Curl, sending a Chrome user agent by hand, and curl sending a HeadlessChrome user agent together with client hints, both received three runnable bodies from the same runner and the same key, so the browser sends something neither guess reproduced. This logs the headers of the include request as the browser actually made it, minus any cookie, so the difference can be read rather than guessed at again. Temporary, alongside the rest of the block, and tracked in issue 24.
Contributor
Author
|
Answered. The full diagnosis is in issue 24. Branch kept so the run can be repeated, but nothing here should be merged. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Temporary, and not for merge. Close it once it has answered the question
in issue 24.
Why
SessionStorageCache_Chromefails the Examples workflow on ubuntu with"the first page must call the json endpoint at least once", and it blocks
pull request 21 and
pull request 22. Neither
causes it. Pull request 21 changes no
.mustachefile and failsidentically to pull request 22, which does, and the test itself arrived
from the shared suite, which
ci/run-integration-tests.ps1 clones
unpinned, between the last green run on 27 July 2026 and the first red
one on 28 August.
The rust integration passes that assertion on a workstation, with the
suite at the same commit CI clones, with both the paid and the free key,
and under both
--headlessand--headless=new. So the difference iswhat the cloud returns to a GitHub runner, which nothing in the logs
shows.
What this prints
The Chrome and ChromeDriver versions, then how many runnable JavaScript
bodies the cloud returns for three header sets. Measured on a
workstation:
HeadlessChromeuser agent, no client hintsHeadlessChromeuser agent, with client hintsThe client only posts when at least one body comes back, so if the runner
returns none where a workstation returns three, that is the answer.
Branched from
mainrather than from either open pull request, so thisrun also shows whether
mainalone fails.Safety
No resource key is printed. The key stays inside the example, and these
requests only ask the local example for its include. The block is
confined to one script and is removed by closing this branch.
Produced with AI assistance under James Rosewell's direction and needs
human review before anything is concluded from it.