Repository navigation
esi pins fastly ^0.12, which blocks the fastly 0.13 upgrade #1122
Description
The esi crate declares fastly = "^0.12". EdgeZero moves to fastly 0.13 (IABTechLab/edgezero#366), and both land in trusted-server-adapter-fastly, so the graph carries two incompatible copies of the same types:
fastly 0.13.1 <- edgezero-adapter-fastly
fastly 0.12.1 <- esi 0.7.2
crates/trusted-server-adapter-fastly/src/esi_assembly.rs passes fastly::http::Response and Request across that boundary, so it fails to compile:
error[E0308]: mismatched types
--> crates/trusted-server-adapter-fastly/src/esi_assembly.rs:96:9
error[E0631]: type mismatch in closure arguments
--> crates/trusted-server-adapter-fastly/src/esi_assembly.rs:124:65
ESI is unconditional in that adapter (not feature-gated), so it cannot be sidestepped.
The fix is one line, upstream
esi needs no source changes. Cloning fastly/esi at v0.7.2 and changing only the manifest range:
-fastly = "^0.12"
+fastly = "^0.13"cargo check -p esi --target wasm32-wasip1 passes clean. With that patched in locally, the entire trusted-server workspace compiles, including the Fastly adapter.
Historical upstream status (as reported when this issue was filed)
fastly/esimainstill readsfastly = "^0.12".- Published
esi0.7.2 declares^0.12(confirmed via the crates.io dependency API). - No open PR addresses it.
fastly/esi#60is the v0.7.1 to v0.7.2 release bump and touches only the workspace version and lockfile.
Options
- Open a one-line PR against
fastly/esiand wait for a release. - Carry the fix on the existing
stackpop/esifork and reference it from[patch.crates-io]until upstream releases. Note the fork'smainis behind upstream (missing v0.7.1 and v0.7.2), so it should branch from upstreamv0.7.2.
Surfaced by #1124 / PR #1123, which the original report said carried a temporary [patch.crates-io] pointing at the fork branch. This issue stays open until the range bump is released upstream and that patch can be dropped.
Done when
- A compatible
esirelease accepts the Fastly SDK version used by EdgeZero without duplicating incompatiblefastly::httptypes across the adapter boundary. - The Fastly adapter builds for
wasm32-wasip1with that release and without the temporary[patch.crates-io]workaround described in the original report. - The dependency decision and any upstream PR or release reference are recorded before this issue is closed.
Current repository note
At main commit 666953a0d, the workspace still pins fastly = "0.12" and esi = "0.7.2"; Cargo.lock has fastly 0.12.1. The original build failure concerns the proposed 0.13 upgrade, not the present 0.12 build.
Activity
aram356 commentedon Sep 7, 2026
Verified end to end with the one-line fix applied locally, on Rust 1.98.1 and Viceroy 0.21.0.
Cloned
fastly/esiat v0.7.2, changed only the manifest range:No source changes to esi.
cargo check -p esi --target wasm32-wasip1compiles clean.With that referenced from
[patch.crates-io]in trusted-server, both Fastly gates pass:cargo clippy-fastly— clean under-D warningscargo test-fastly— 166 adapter tests (ESI assembly included), 2290 core, 2 js, 21 openrtb, 3 doctests; 0 failedSo the version range is genuinely the only obstacle, and the resulting build is exercised rather than merely compiling.
Patch `esi` to a fork carrying the fastly 0.13 range
aram356 commentedon Sep 7, 2026
Branch pushed to the fork: stackpop/esi@
chore/fastly-0.13(75bfbb396), branched from upstreamv0.7.2.It turned out to be seven lines, not one. The library pin was the blocker, but the six examples pin
fastlythemselves, so they move with it — leaving them at 0.12 would build each example against a different SDK than theesiit links, which is the same two-copies problem one level down. Still no source changes to esi.PR #1123 now references that rev via
[patch.crates-io], and both Fastly gates pass against it:fastly0.12 drops out of the graph entirely; one copy remainscargo clippy-fastly— clean under-D warningscargo test-fastly— 166 adapter + 2290 core + 2 js + 21 openrtb + 3 doctests, 0 failedThe patch in #1123 is temporary and marked as such; it should be dropped once the range bump is released upstream. An upstream PR against
fastly/esihas not been opened yet.aram356 commentedon Sep 7, 2026
esi's own test suite passes against fastly 0.13: 163 passed, 0 failed on
wasm32-wasip1under Viceroy 0.21.0, on the fork branch as pushed.So the change is verified on both sides — esi's suite against the new SDK, and trusted-server's full CI against the patched esi. That is the evidence an upstream PR would need.
Merge main and move EdgeZero to v0.0.10
aram356 commentedon Oct 16, 2026
Status check on 2026-10-16: still no published version that works, so the
[patch.crates-io]fork reference stays for now.esi0.7.2 (2026-08-20) is still the newest release and still declaresfastly = "^0.12". There is no 0.7.3, 0.7.4 or 0.8.0.fastly/esimainstill reads^0.12, and no open PR addresses it.binary-install-style workarounds do not apply here; the range is the only blocker.Verified by removing the patch on the upgrade branch and resolving against the published crate:
That is the original failure: the published crate pulls a second copy of the Fastly SDK into a graph where EdgeZero requires 0.13, and the two meet in
esi_assembly.rs. The working tree was restored afterwards; PR #1123 is unchanged and passing 23/23.The exit condition for this issue is unchanged and now measured: a published
esiwhosefastlyrequirement admits 0.13. At that point the patch block inCargo.tomlbecomes a plain version pin and this issue closes. The one-line change that achieves it is onstackpop/esiatchore/fastly-0.13(rev 75bfbb396) and has not been proposed upstream.Upgrade to Rust 1.98.1 and align dependencies with EdgeZero (#1123)