Repository navigation
Upgrade to Rust 1.98.1 and align dependencies with EdgeZero - #1123
Conversation
Match the toolchain and shared dependency pins to EdgeZero PR #366 so both workspaces resolve the same major versions. Toolchain: Rust 1.95.0 to 1.98.1, Node 24.12.0 to 24.20.0, Fastly CLI 15.1.0 to 16.0.0, Viceroy 0.17.0 to 0.21.0, wasmtime 44.0.1 to 48.0.1. CI derives each from `.tool-versions`, so only that file and `rust-toolchain.toml` pin them. EdgeZero moves from tag v0.0.7 to the PR #366 head revision. The latest tag, v0.0.8, still carries the 1.95 toolchain and the previous majors, so it would contradict the pins below. Restore a tag once #366 merges. Shared majors: fastly and log-fastly 0.12 to 0.13, spin-sdk ~6.0 to ~7.0, validator 0.20 to 0.21, sha2 0.10 to 0.11. brotli stays at 8 for the reason recorded in #366: async-compression still resolves 8, so taking 9 adds a second decompressor stack rather than replacing one. sha2 0.11 moves RustCrypto to `hybrid_array`, which forces two further majors this workspace needs but #366 did not: hmac 0.12 to 0.13 and chacha20poly1305 0.10 to 0.11. Their fallout is three lines: - `new_from_slice` moved from `Mac` to `KeyInit`, so `ec/generation.rs` and `s3_sigv4.rs` bring that trait into scope. HMAC output is unchanged, verified byte-for-byte against 0.12 for both a short key and a block-length key, so persisted EC IDs and SigV4 signatures stay valid. - `Array` does not implement `LowerHex` as `GenericArray` did, so `settings_data.rs` formats via `hex::encode`. sha2 0.11 also pulls crypto-common 0.2, which depends on getrandom 0.4. That line renamed the browser RNG feature from `js` to `wasm_js`, so the Cloudflare target needs a second getrandom entry to enable it. The Fastly adapter does not build on this branch: `esi` 0.7.2 pins fastly ^0.12 while EdgeZero requires 0.13, and both meet in `esi_assembly.rs`. Upstream `fastly/esi` main is still on ^0.12.
Point the Viceroy install command at 0.21.0 in the getting-started,
testing and error-reference guides, the integration-tests README, and
the three scripts that name it in their prerequisites.
Fill in the Rust and NodeJS versions in the getting-started
prerequisites. Both were `{{RUST_VERSION}}` / `{{NODEJS_VERSION}}`
placeholders with no substitution step anywhere in the repo, so the
published page rendered the braces literally.
`docs/superpowers/**` keeps its 1.95 and 0.17.0 mentions: those are
dated design records describing the stack as it stood when each was
written.
`hybrid_array` deprecates `from_slice` in favour of `TryFrom`, which is an error under the workspace's `-D warnings` clippy gate. The encode path builds a fixed `[u8; 24]`, so it converts infallibly via `XNonce::from`. The decode path takes a runtime slice, so it uses `XNonce::try_from` and returns `None` on a mismatch, matching the function's existing `Option` contract; the preceding length check already guarantees 24 bytes, so this is unreachable in practice and replaces a path that would previously have panicked. Both conversions yield an owned `XNonce` where `from_slice` yielded a reference, so the three use sites borrow explicitly.
aram356
added
dependencies
`publisher.rs` imports `std::io::Write` at file scope, and the test module's `use super::*` already brings it in, so the module's own `Write as _` is redundant. Rust 1.98 reports it as an unused import, which is an error under the workspace's `-D warnings` gate. Confirmed new to the toolchain rather than pre-existing: clippy on `main` under 1.95 is clean against the identical pair of imports.
`run.rs` imports `Parser` at file scope, and the test module's `use super::*` already brings it in, so the module's own `Parser as _` is redundant. Same shape as the `publisher.rs` case: new under Rust 1.98, and an error under `-D warnings`. Missed in the first local pass because `cargo check` on the CLI runs neither `--all-targets` nor `-D warnings`; CI's clippy does both.
|
CI status after the two Rust 1.98 unused-import fixes. Passing: cross-adapter parity, cloudflare (native + wasm32-unknown-unknown), spin (native + wasm32-wasip1), ts CLI (native), vitest, format-typescript, format-docs, CodeQL. Failing — all four for the same reason: Each fails with the same two errors at the same two lines: That is #1122 and nothing else — no other failure mode appears in any of the four logs. Every job that does not build the Fastly adapter is green. Locally, with esi patched to |
`esi` 0.7.2 pins `fastly = "^0.12"` while EdgeZero requires 0.13. Both land in `trusted-server-adapter-fastly`, and `esi_assembly.rs` passes `fastly::Request` and `Response` across that boundary, so the two copies meet and the adapter fails to compile. The fork changes only the version ranges, in the library and the six examples that pin `fastly` themselves. No source changes: the crate compiles and its suite passes unmodified against 0.13. `fastly` 0.12 now drops out of the graph entirely, leaving one copy. Temporary. Drop this patch once the range bump is released upstream; tracked in #1122.
|
All CI checks pass with the esi patch in place. Every job that was failing on the esi type conflict is now green: The patch points at stackpop/esi@
The patch is temporary and commented as such. It should be dropped once the range bump is released upstream — #1122 tracks that. |
`{{RUST_VERSION}}` and `{{NODEJS_VERSION}}` were replaced with literal
versions on the mistaken belief that nothing substituted them. VitePress
does: `docs/.vitepress/config.mts` installs a markdown hook that reads
`.tool-versions` and replaces `{{<TOOL>_VERSION}}` for every tool listed
there. `{{FASTLY_VERSION}}`, four lines below in the same file, was
already relying on it.
Hardcoding the numbers dropped the guide out of that mechanism, so it
would have silently gone stale at the next toolchain bump. The
placeholders now resolve from the versions updated earlier in this
branch; verified against a real `npm run build`, whose rendered HTML
reads "Rust 1.98.1", "NodeJS 24.20.0" and "Fastly 16.0.0" with no
placeholder left unsubstituted.
Three conflicts, resolved as follows. `CLAUDE.md` — main made it a symlink to `AGENTS.md` (#923) while this branch still edited it as a regular file. Took main's symlink and moved the toolchain-table, Viceroy-install and `rust-toolchain.toml` version edits into `AGENTS.md`, which is now the real file. `Cargo.toml` — main moved EdgeZero from tag v0.0.7 to v0.0.8; this branch pins the head of EdgeZero PR #366. Kept the revision pin, because v0.0.8 still carries fastly 0.12, sha2 0.10, spin-sdk ~6.0 and validator 0.20, so taking main's side would have undone every major this branch exists to land. Verified against the published tag rather than assumed. Refreshed the pin to #366's current head, 9ba4eae7b, which had moved on since 40c52e3f; the one new commit adds a Spin 4.1 floor and a migration doc, no dependency changes. Main's new `cssparser` entry is preserved. `Cargo.lock` — regenerated from the resolved manifest. Resolves to a single fastly 0.13.1 with the new majors intact and the esi fork patch still in place. Verified on the merged tree: all six clippy targets clean under `-D warnings`, `cargo fmt` clean, test-fastly (191 adapter + 2661 core + 2 js + 21 openrtb + 3 doctests), test-axum, test-cloudflare, test-spin, parity (13), CLI (212), 901 JS tests, and both format gates.
A merge of main was pushed to this branch from the GitHub web UI while the local merge was under test. Merging it in rather than force-pushing over it keeps that commit in the history. That merge was made against 640e93d, an older main tip, so it predates the eight commits that landed after it, #923 among them. Merging it into the local merge, which is against current main, is what brings the branch up to date; taking it alone would have left the PR conflicting. Where the two resolutions differ, this keeps the local one: `CLAUDE.md` stays the symlink to `AGENTS.md` that #923 introduced, with the version edits in `AGENTS.md`, and `cssparser` from #1106 stays in the manifest. Both were lost in the web-UI resolution because the commits that introduced them were not in its base. Re-verified after the merge: fmt and clippy-fastly clean, test-fastly (191 + 2661 + 2 + 21 + 3), test-axum, test-cloudflare, test-spin.
EdgeZero v0.0.10 carries the majors this branch exists to land (fastly 0.13, sha2 0.11, spin-sdk ~7.0, validator 0.21), so the revision pin on PR #366 is no longer needed. All six crates move to the tag and the comment explaining why a tag would not work is gone with it. Six conflicts, resolved as follows. `.tool-versions` and the `AGENTS.md` toolchain table - main added AWS CLI and Terraform entries and reflowed both tables. Kept main's structure and rows, carried this branch's upgraded versions into them. `Cargo.toml` - took v0.0.10 over main's v0.0.9. In the second hunk main added `serde_yaml_ng` and `similar` adjacent to the `sha2` line; kept both and held sha2 at 0.11. Verified that every dependency main added since the merge base survives: assert_cmd, gix, predicates, rpassword, tracing, serde_yaml_ng, similar. `crates/trusted-server-integration-tests/README.md` - main rewrote the section as "Test surfaces" and dropped the prerequisites list, whose only stake here was a Viceroy version string that no longer appears. Took main's rewrite whole. `docs/guide/testing.md` - main trimmed the comments and added a `rustup target add` line. Kept main's shape with the new Viceroy version; the prose above it already states the requirement. `Cargo.lock` - regenerated. Resolves to a single fastly 0.13.1 with the new majors intact and the esi fork patch still in place: esi 0.7.2 is still the newest published version and still pins fastly ^0.12, so issue #1122 stays open. One source fix. `ec/pull_sync_marker.rs`, added to main after this branch was cut, calls `HmacSha256::new_from_slice`, which hmac 0.13 moved from `Mac` to `KeyInit`. Imported the trait as `KeyInit as _`, matching the two sites already fixed here and the file's own style. Verified on the merged tree: all eight clippy targets clean under `-D warnings` (including the new clippy-cli and clippy-codegen), fmt clean, test-fastly (221 adapter + 2944 core + 10 js + 10 + 21 openrtb + 4 doctests), test-fastly-reuse (221), test-axum, test-cloudflare, test-spin, parity (17), CLI (858), 1211 JS tests across 50 files, the JS and docs format gates, and the markdown gate outside docs/.
ChristianPavilonis
left a comment
ChristianPavilonis
left a comment
There was a problem hiding this comment.
Please declare and enforce the Spin 4.1+ runtime minimum introduced by the SDK 7 upgrade. Components built with this SDK cannot start on Spin 4.0.x because it cannot link wasi:http/types@0.3.0.
Document the prerequisite in the Spin guide and add a version preflight to the smoke script so unsupported runtimes fail with a clear message.
`spin-sdk` 7 imports `wasi:http/types@0.3.0`, which Spin 4.0.x does not provide, so the SDK upgrade in this branch makes the component unstartable on those runtimes. Nothing in the build catches it: the component compiles, `cargo test-spin` passes, and only `spin up` fails, reporting an unresolved import against the linker. `scripts/smoke-common.sh` gains `smoke_require_spin_version`, which parses `spin --version` and refuses anything below 4.1.0 with a message naming the found version, the reason, and the install URL. It fails closed when the version cannot be parsed or `spin --version` does not run, so a broken toolchain cannot look like a pass. Comparison uses `sort -V`, so 4.10.0 orders above 4.1.0 as it should. The smoke calls it after the existing command checks, before building or starting the app. `docs/guide/spin.md` gains a prerequisites section carrying the requirement, the linker error it otherwise produces, and the note that the smoke now catches it. The "With the Spin CLI installed" line that opens the verification section now names the version. No `.tool-versions` entry. asdf has no first-party Spin plugin, so a pin would make `asdf install` fail until every developer added a third-party one, and CI never installs or runs the Spin runtime (`test-spin` only checks, builds and tests). The preflight enforces the floor where the runtime is actually used. Verified: the gate accepts 4.1.0, 4.10.0, 5.0.0 and 10.0.0, rejects 4.0.0, 4.0.3 and 3.9.9, and fails closed on unparseable output and a non-zero exit. shellcheck clean on both scripts. Running the real `./scripts/smoke-spin.sh` passes the preflight against the local Spin 4.1.0 and proceeds to build and launch; it then fails on an app-config diagnostic assertion that fails identically on `main` at fa9837f, so that failure is pre-existing and unrelated to this change.
Adds `spin 4.1.0` to `.tool-versions` and makes the smoke preflight read its minimum from that line instead of hardcoding one, so the pin and the check cannot drift. A missing `spin` entry now fails closed rather than silently skipping the gate. Every consumer of `.tool-versions` looks up one tool at a time, with `awk '$1 == "..."'` or `grep '^<tool> '`, so the new line is inert to the workflows and scripts that read the file; the helper uses the same awk form. CI never calls `asdf install`, so an entry asdf cannot resolve does not break it. That resolution gap is real, though: asdf has no first-party Spin plugin, so `asdf install` will not provide this one. The Spin guide now says so, and points at the install guide or a community plugin. The pin records the required version and is what the smoke checks against. Also adds the Spin row to the `AGENTS.md` toolchain table, which lists the other pinned tools. Verified: the helper resolves the pin from any working directory via `BASH_SOURCE`; bumping the pin to 9.9.9 in a scratch copy rejects the local Spin 4.1.0, and deleting the line reports the missing pin, so the file genuinely drives the floor. The version gate is unchanged, still accepting 4.1.0, 4.10.0 and 10.0.0 and rejecting 4.0.3 and 3.9.9. shellcheck clean, `cargo check-spin` clean, `cargo test-spin` 88 tests passing, both markdown format gates clean.
|
CI status at 5c850c6: 20 passing, 1 failing. The failure is external to this branch.
The Evidence that this is not from this branch:
I have not tried to fix it here. It needs either a Everything else is green, including both Spin jobs and the CLI on macOS and Ubuntu. |
The Cloudflare bundle step installs `worker-build` without `--locked`, so Cargo re-resolves its whole dependency tree on every install. That tree is not resolvable: `worker-build` depends on `binary-install` 0.4.1, which requires `zip ^2.1.3`, and the entire `zip` 2.x line is yanked. `binary-install` 0.4.1 is still the newest release, and the current `worker-build` 0.8.7 depends on it too, so there is no version pair to upgrade to. This surfaced now rather than in May 2025, when `zip` 2.6.1 was yanked, because a warm Cargo index kept serving a resolvable answer. Yanking `zip` 9.0.2 on 2026-10-16 at 03:33Z refreshed the index, and the next fresh resolve failed. Runs from 21:27Z the previous evening passed on the stale index, which is why other open PRs look unaffected. `--locked` installs against the lockfile `worker-build` publishes, which pins a working `zip`, so upstream yanks in versions it never selected cannot break the install. Verified both directions with the exact command the step runs: `cargo install -q --force --version "=0.8.5" --locked worker-build` succeeds, and the same command without `--locked` fails on the yanked `zip` versions. Matches the `--locked` already used for the Viceroy install in the same workflow.
|
Correcting my previous comment, and fixing the failure in b17d64b. What I got wrong. I said the What is actually happening. So this was a latent breakage in the install command, not something this branch introduced, and not a new upstream event. It will hit The fix is one flag: No version changes and no vendoring, and it matches the |
dhruv8sh
left a comment
dhruv8sh
left a comment
There was a problem hiding this comment.
Summary
Toolchain bump to Rust 1.98.1 plus the dependency majors aligned with EdgeZero v0.0.10. The source changes address the actual API breaks with no lint suppressions, the esi fork patch is a minimal range bump, and CI is fully green. Approving; the comments below are non-blocking.
1 of the inline comments below carries a one-click GitHub
suggestion— use Commit suggestion to apply it. The remaining comments describe changes in prose because they touchCargo.lockor a second manifest and can't be auto-applied.
Non-blocking
- ♻️ Drop the
getrandom_04wiring by disabling chacha20poly1305's default features — see inline atCargo.toml:82 - ⛏
getrandom_04comment attributes the dependency to the wrong crate — see inline atCargo.toml:78-81 - ⛏ Pin the esi fork by full SHA — see inline at
Cargo.toml:145 - 🤔
spinin.tool-versionsmakesasdf installcomplain — see inline at.tool-versions:6
Cross-cutting / body-level findings
- 📝 PR description is out of date with the code — the description says the esi patch "is not committed here" and that "Fastly gates will be red in CI until #1122 is resolved", but commit e35e19c adds
[patch.crates-io] esi = { git = "https://github.com/stackpop/esi", rev = "75bfbb396" }(Cargo.toml:144-145) and every check, Fastly included, is green. It also mentions an integration-tests README Viceroy update that isn't in the diff (harmless — no README pins a Viceroy version), and doesn't cover the later Spin 4.1 minimum (.tool-versions,docs/guide/spin.md,smoke_require_spin_version) or the Cloudflareworker-build --lockedchange. Worth refreshing before merge, since it likely becomes the squash commit text and currently implies #1122 still gates this PR. - 👍 Careful upgrade work — comparing HMAC 0.12 vs 0.13 output byte-for-byte to protect persisted EC IDs and SigV4 signatures, fixing the real API changes rather than adding
#[allow], theTryFromdecode path removing a latent panic, and keeping the fork to a single range bump on the v0.7.2 tag (verified:stackpop/esi@75bfbb396d4chas thefastly/esiv0.7.2 tag as its sole parent and only changesfastly = "^0.12"→"^0.13"inesi/Cargo.toml, the six examples, and the lockfile).
CI Status
- Analyze (actions): PASS
- Analyze (javascript-typescript): PASS
- Analyze (python): PASS
- Analyze (rust): PASS
- browser integration tests: PASS
- cargo check/build/test (spin native + wasm32-wasip1): PASS
- cargo check (cloudflare native + wasm32-unknown-unknown): PASS
- cargo fmt: PASS (required)
- cargo test: PASS (required)
- cargo test (axum native): PASS
- cargo test (cross-adapter parity): PASS
- cargo test (ts CLI, native) (macos-latest): PASS
- cargo test (ts CLI, native) (ubuntu-latest): PASS
- CLAUDE.md symlink guard: PASS
- CodeQL: PASS
- format-docs: PASS (required)
- format-typescript: PASS (required)
- integration tests: PASS
- integration tests (Fastly EC lifecycle): PASS
- PBS Terraform and Compose checks: PASS
- prepare integration artifacts: PASS
- vitest: PASS
Three conflicts, all from main and this branch changing the same lines. `Cargo.toml` - main moved the EdgeZero git URLs from `stackpop` to `IABTechLab` (#1323) while this branch moved the tag to v0.0.10. Took both: the new org at v0.0.10. Verified the tag exists in the new organization at the same commit the old one pointed to, 85d933b8044d, so this is a URL change and not a different dependency. `crates/trusted-server-adapter-cloudflare/build.sh` - main landed the same `--locked` fix for the `worker-build` install that this branch carried, independently. The commands are functionally identical, so this keeps main's wording and flag order. `Cargo.lock` - regenerated. Resolves EdgeZero from `github.com/IABTechLab/edgezero` at v0.0.10 with a single fastly 0.13.1 and the new majors intact. #1323 moved only the EdgeZero references; the `stackpop/esi` ones are untouched on main, so the esi patch block still matching main's spelling is correct and stays as it is. Verified on the merged tree: all eight clippy targets clean under `-D warnings`, fmt clean, test-fastly (221 adapter + 2944 core + 10 js + 10 + 21 openrtb + 4 doctests), test-fastly-reuse (221), test-axum, test-cloudflare, test-spin, parity (17), CLI (858), 1211 JS tests, and all three format gates.
Three review findings from dhruv8sh on #1123. The `getrandom_04` renamed-package entry is gone, and with it the `wasm_js` wiring in `trusted-server-core`. The entry was justified by a wrong diagnosis: `sha2` does not pull getrandom 0.4. `crypto-common` 0.2 declares it `optional = true` behind a `getrandom` feature, and the only thing enabling that feature is `chacha20poly1305`'s own default `getrandom` → `aead/getrandom` → `crypto-common/getrandom`. Turning off that default removes getrandom 0.4 from the Cloudflare graph entirely rather than configuring it. Safe because the XChaCha nonce is derived from SHA-256 for stable tokens, not drawn from the AEAD's RNG: `http_util.rs` imports only `Aead` and `KeyInit`, and nothing in the workspace calls `generate_nonce` or `generate_key`. The two `OsRng` uses are ed25519 key generation through `rand`, untouched by this. Confirmed the ciphertext does not move. A scratch crate encrypting a fixed URL with a fixed secret produces the same bytes with default features on and off: 5a0f9fca0c02d1f46d2e00e67c3fd00ba5d825784329f4b3b5b588bbbe77b7ca... so persisted proxy URL tokens stay valid. `cargo tree -i getrandom@0.4.3` on `wasm32-unknown-unknown` now reports nothing; the crate remains only on `wasm32-wasip1` via esi's `rand` and `uuid`, which have native RNG and never needed the feature. The esi patch rev is now the full 40-character SHA rather than a 9-character prefix, which is unambiguous on fetch. Verified it is the same commit the lockfile already resolved. On the fourth finding, the `spin` pin in `.tool-versions`: keeping it. `fastly` and `viceroy` have no asdf plugin at all and have been pinned there all along, while `spin` at least has a community one, so the file is already an inventory of required versions rather than a strictly asdf-installable manifest. `docs/guide/onboarding.md` says "asdf or another version manager", and `docs/guide/spin.md` already documents the missing plugin. CI is unaffected: every consumer greps one tool at a time. Verified: fmt clean, clippy-cloudflare-wasm, clippy-fastly and clippy-spin-wasm clean, test-fastly (221 + 2944 + 10 + 10 + 21 + 4), test-cloudflare, test-axum all passing.
|
Merged main and addressed the review feedback. Merge (847c9b2) — three conflicts. Review fixes (4c5ca8a) — all four of @dhruv8sh's findings, with replies on each thread:
PR description — rewritten. It claimed the esi patch was "not committed here" and that the Fastly gates would be red until #1122, both false since e35e19c; it also mentioned an integration-tests README change that was never in the diff, and omitted the Spin 4.1 minimum and the Verified locally after both commits: fmt clean, eight clippy targets clean under |
Summary
Aligns the toolchain and shared dependency pins with EdgeZero PR stackpop/edgezero#366, so both workspaces resolve the same major versions instead of fighting each other.
The Fastly adapter does not build on this branch. That is a single external blocker, tracked in #1122 and detailed at the bottom. Everything else — core, Axum, Cloudflare, Spin, CLI — compiles, lints and tests clean.
Toolchain
CI derives every one of these from
.tool-versions, so only that file andrust-toolchain.tomlpin them — no workflow changes needed.EdgeZero
Pinned to
tag = "v0.0.10". Earlier revisions of this branch carried a revision pin on the head of #366, because no release yet contained the majors below. v0.0.10 does (fastly 0.13, sha2 0.11, spin-sdk ~7.0, validator 0.21), so the pin is a clean tag again and the comment explaining the workaround is gone.Note that
mainpins v0.0.9, which does not carry them; this PR moves one release ahead rather than reverting to main's tag. The git URLs areIABTechLab/edgezero, following main's org move (#1323); v0.0.10 exists there at the same commit (85d933b8044d) the oldstackpoptag pointed to.Dependency majors
Matched to #366:
fastlyandlog-fastly0.12 → 0.13,spin-sdk~6.0 → ~7.0,validator0.20 → 0.21,sha20.10 → 0.11.brotlistays at 8, for the reason #366 records and measures:async-compressionstill resolves brotli 8, so taking 9 on the direct dependency adds a second decompressor stack rather than replacing one.Two further majors this workspace needs but #366 did not.
sha20.11 moves RustCrypto tohybrid_array, and the ecosystem has to cross together:hmac0.12 → 0.13 andchacha20poly13050.10 → 0.11. Without them,XChaCha20Poly1305::newreceives anArraywhere it expects aGenericArray.Source changes — six lines, no lint suppressions
Every fix addresses the actual API change. Nothing is silenced with
#[allow].new_from_slicemoved fromMactoKeyInitin hmac 0.13 —ec/generation.rs,s3_sigv4.rsandec/pull_sync_marker.rsbring the trait into scope withas _. (The third arrived onmainafter this branch was cut and surfaced in the merge.)Arraydoes not implementLowerHexasGenericArraydid —settings_data.rsformats viahex::encode. (hexis already a dependency, already used for exactly this nearby. Hand-rolling hex is a trap: it tripsindexing_slicing, thenas-truncation, thenarithmetic_side_effectsin turn.)Array::from_sliceis deprecated in favour ofTryFrom, which is an error under-D warnings. Inhttp_util.rsthe encode path builds a fixed[u8; 24]and converts infallibly viaFrom; the decode path takes a runtime slice and usesTryFrom, returningNoneon a mismatch to match the function's existingOptioncontract — replacing a path that would previously have panicked.publisher.rs(std::io::Write) andcli/src/run.rs(clap::Parser) each import the trait at file scope, and the test module'suse super::*already brings it in, so the module's ownas _copy is unused. Confirmed new to the toolchain rather than pre-existing: clippy onmainunder 1.95 is clean against the identical pairs.chacha20poly1305 default features
sha20.11 pullscrypto-common0.2, which declares an optional getrandom 0.4 dependency. The only thing enabling it ischacha20poly1305's own defaultgetrandomfeature (→aead/getrandom→crypto-common/getrandom), which onwasm32-unknown-unknownis a hardcompile_error!.Rather than configure that crate, this disables the default:
chacha20poly1305 = { version = "0.11", default-features = false, features = ["alloc"] }. The XChaCha nonce here is derived from SHA-256 for stable tokens and never drawn from the AEAD's RNG, so the feature was unused.cargo tree -i getrandom@0.4.3on the Cloudflare target now reports nothing.Verified the ciphertext does not move: a scratch crate encrypting a fixed URL with a fixed secret produces identical bytes with the default features on and off, so persisted proxy URL tokens stay valid.
Behaviour is unchanged, and this was verified rather than assumed
hmac 0.13 could plausibly have changed digests for keys shorter than the block size — which would silently invalidate every persisted EC ID and S3 SigV4 signature. Built scratch crates against both versions and compared:
Byte-identical. Existing identities remain valid.
Documentation
Viceroy install command updated to 0.21.0 in the getting-started, testing and error-reference guides, and three scripts that name it in their prerequisites.
The getting-started prerequisites keep their
{{RUST_VERSION}}and{{NODEJS_VERSION}}placeholders.docs/.vitepress/config.mtsinstalls a markdown hook that reads.tool-versionsand substitutes{{<TOOL>_VERSION}}for every tool listed there, so those lines track the pins automatically and need no edit. Verified against a realnpm run build: the rendered HTML reads "Rust 1.98.1", "NodeJS 24.20.0" and "Fastly 16.0.0".docs/superpowers/**keeps its 1.95 and 0.17.0 mentions: dated design records describing the stack as it stood when each was written. Same exclusion #366 made.The blocker: esi pins fastly ^0.12 (#1122)
esi0.7.2 declaresfastly = "^0.12"while EdgeZero requires 0.13. Both land intrusted-server-adapter-fastly, andesi_assembly.rspassesfastly::http::Response/Requestacross that boundary, so it sees two incompatible copies of the same types. ESI is unconditional there, not feature-gated.The fix is one line and needs no source changes to esi. Cloning
fastly/esiat v0.7.2 and changing only the manifest range to^0.13compiles clean, and with that patched in locally the entire workspace builds, Fastly adapter included.Upstream
mainstill reads^0.12, and no open PR addresses it —fastly/esi#60is the v0.7.2 release bump, touching only the workspace version and lockfile. #1122 lays out the two paths (upstream PR and wait, or carry it on the existingstackpop/esifork behind[patch.crates-io]).Closes
Closes #1124
Depends on #1122 for the temporary
esipatch — that one stays open until the range bump is released upstream and the patch can be dropped.Test plan
Verified on
rustc 1.98.1, Node 24.20.0, Viceroy 0.21.0:cargo fmt --all -- --checkcargo clippy-axum,clippy-cloudflare,clippy-cloudflare-wasm,clippy-spin-native,clippy-spin-wasm— all clean under-D warningscargo test-axum— 38 passedcargo test-cloudflare— 40 passedcargo test-spin— 80 passedcargo test --package trusted-server-cli --target aarch64-apple-darwin— 209 passed, plus clippy--all-targets -D warningsnpm run formatnpm run formatAll gates run unconditionally now that the esi patch is committed:
cargo clippy-fastly— clean under-D warningscargo test-fastly— 221 adapter + 2944 core + 10 js + 10 + 21 openrtb + 4 doctestscargo test-fastly-reuse— 221cargo clippy-cliandcargo clippy-codegen— cleanCI: all 23 checks green, including the integration, browser and Fastly EC lifecycle suites.
Review notes
The
[patch.crates-io]esi entry is the one piece of unusual wiring, and #1122 carries the context for removing it.