feat(net): accept persistent consumer cookie stores - #98
Merged
Merged
Conversation
added 6 commits
September 18, 2026 01:55
A dependency-ordered list of fifteen crate names, a second list of four released separately, a check that the two together covered every publishable member, a `cargo metadata` per crate to read its version, and a crates.io query per crate to ask whether that version existed. 248 lines to 107. Every incident the old comments recorded was caused by that script. Crates fell out of the list and stopped being released while the job reported success on every run. A `[ -n "$x" ] && echo` returned 1 under `set -e` and failed a run that had already uploaded every crate. `cargo publish --workspace` has no list to fall out of. The crates on their own version lines need no special handling: each publishes at the version in its own manifest, and one already on crates.io is skipped. One thing cargo does not do is tolerate a version already on the registry - it fails the whole run rather than skipping that crate, and a dry run only warns. Re-running a partial release has to work, so that one error passes and nothing else does.
This branch predated master's 0.4.10 and carried two problems that a merge would have shipped. It regressed the workspace version to 0.4.9, because the branch was cut before the 0.4.10 release landed. The rebase fixes that on its own. It also took blitz-net off `version.workspace` and pinned it to 0.4.10, which is already on crates.io. The publish job skips a version that exists, so the cookie-store feature this branch is for would never have reached a consumer, and the run would have reported success. Splitting a crate onto its own version line is also how ps-vello ended up publishing its engine at 0.10.1 beside four crates at 0.2.0. So blitz-net inherits again and the workspace bumps once. One release, 0.4.11, carrying the cookie-store hook, the Boa caret relaxation and the publish simplification, across the twelve engine crates.
pathscale
force-pushed
the
fix/provider-cookie-store-hook
branch
from
September 17, 2026 18:57
3129aef to
5dc8048
Compare
The suite ran on every push of every branch and took minutes. It is upstream's, sized for an engine many people contribute to, and it is not what anything is gated on: the checks that catch real breakage run here in seconds. It is `workflow_dispatch` now. Turning it off meant running it locally, which surfaced four things it had been failing on, none of them from this branch: - an unused `Document as _` import in the scroll_extent test - four `let _ = handle.set_focus(true)` in dioxus-native-dom tests. Dropping the future is deliberate there - the request lands on the command queue as the future is built, and the tests are about what happens before anything drives it - so they say `drop(..)` now, which is the same behaviour without the lint. - `[profile.tiny.package.vello_cpu]`, left behind when the crate became `ps-vello-cpu`, which cargo reported on every single build. The local guidance at the top of the file drops `--all-targets`. It builds every example, test and bench and takes six minutes rather than one, and CI's own clippy step never used it either.
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.
Chuzz needs one persistent cookie jar to participate in the provider's complete HTTP exchange. Previously an embedder could only ask Blitz to create its internal ephemeral jar, so a separate persistent wrapper missed cookies set on intermediate redirects and final error responses.
This re-exports reqwest's cookie-provider contract from
blitz-netand adds a constructor that installs an embedder-owned jar on the provider's existing client. The fixture proves the same jar supplies the first request, receives the redirect cookie before the redirected request, and receives the final error response cookie.ps-blitz-netmoves independently to 0.4.10; the rest of the workspace remains at its existing version. The ps-boa engine, runtime and GC dependencies use the compatible^1.0range; a fresh no-lock resolution selects one published 1.0.6 family. The publish workflow now asks Cargo metadata for versions instead of parsing Cargo.toml text.Validation:
cargo fmt --all -- --checkcargo test -p ps-blitz-net --all-features(13 passed)cargo clippy -p ps-blitz-net --all-targets --all-features -- -D warningscargo check -p ps-blitz-net --no-default-featurescargo check -p ps-blitz-net --no-default-features --features cookiescargo package -p ps-blitz-net --allow-dirty