fix: build a headless binary without the browser chrome, and name the TLS provider - #44
Closed
pathscale wants to merge 2 commits into
Closed
fix: build a headless binary without the browser chrome, and name the TLS provider#44pathscale wants to merge 2 commits into
pathscale wants to merge 2 commits into
Conversation
added 2 commits
September 9, 2026 18:05
`build_frontend` ran unconditionally, so `cargo build --bin chuzz-headless
--no-default-features` shelled out to `bun run build` in
`apps/chuzz/frontend` for assets that binary never links. `frontend.rs` is
the only consumer of the generated module and is already behind `gui`.
On a machine without `apps/chuzz/frontend/node_modules` the build script
panicked instead:
error: script "layouts:local" exited with code 127
error: script "prebuild" exited with code 127
That is every runner using the `headless-host` action, which installs the
site under test's dependencies and has no reason to install this crate's, so
the whole fleet's QA went red in the host build step.
Verified both ways with `node_modules` moved aside: the headless build now
finishes, and `--bin chuzz-gui` still fails there with the error above,
which is the proof the gate did it rather than something else.
The helpers move behind the same feature so an unused import does not become
a denied warning.
`rustls` picks its provider from crate features and panics at the first handshake when the graph enables neither `ring` nor `aws-lc-rs`, or both. Features are additive across a graph, so which of those holds is an outcome of resolution rather than a decision anyone made, and with no lockfile it is not fixed at any point in time: one dependency picking up `ring` in a later release is enough to turn every `https://` fetch and every `wss://` connection into a panicked worker on the next runner that resolves it. It was hit on a fresh resolution during QA work, on `rustls 0.23.43`, and went away on re-resolution to 0.23.44. Today's graph enables `aws-lc-rs` alone, so this is latent rather than reproducible here, which is exactly the problem: nothing holds it there. The failure does not look like a browser failure. The socket never opens, Solid halts reactivity on the escaped error, and the page collapses to unnamed nodes, so a QA run reports a broken site. Both binaries now install a named provider before anything can reach the network. Verified by capturing an https page end to end.
Owner
Author
|
Folded back into #43. One PR per repo; merge order does the rest. |
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.
Two failures with one cause: dropping the committed lockfile removed assumptions these places relied on. Merging this publishes nothing (the release job is separately broken, repaired in the follow-up PR), which is deliberate: it unblocks the fleet's CI now while chuzz still ships exactly one version later.
A headless build built the browser chrome, and took the fleet's QA red
build_frontendran unconditionally, socargo build --bin chuzz-headless --no-default-featuresshelled out tobun run buildfor assets that binary never links.frontend.rsis its only consumer and is already behindgui.Without
apps/chuzz/frontend/node_modulesthe build script panicked instead, which is every runner using theheadless-hostaction (it installs the site under test's dependencies and has no reason to install this crate's):Verified with
node_modulesmoved aside: the headless build finishes, and--bin chuzz-guistill fails there with the error above. That second half is the proof the gate did it rather than something else.TLS picked its provider by resolution
rustlsselects its crypto provider from crate features and panics at the first handshake when the graph enables neitherringnoraws-lc-rs, or both. Features are additive across a graph, so with no lockfile that is not fixed at any point in time: one dependency picking upringin a later release turns everyhttps://andwss://into a panicked worker on the next runner that resolves it.It was hit on a fresh resolution during QA work on
rustls 0.23.43and went away on re-resolution to 0.23.44. Today's graph enablesaws-lc-rsalone, so it is latent rather than reproducible here, which is the problem: nothing holds it there.It does not present as a browser failure. The socket never opens, Solid halts reactivity on the escaped error, and the page collapses to unnamed nodes, so a QA run reports a broken site.
Both binaries now install a named provider before anything reaches the network. Verified by capturing an https page end to end.