divine-mobile: Skill for Claude Code

Fastly Compute native test linker failure

Problem

Fastly Compute Rust binaries link against libfastly, which provides FFI symbols that only exist when targeting wasm32-wasip1. On a native host (macOS, Linux x86_64, Linux arm64), the FFI symbols are absent, so linking a test binary for the Fastly Compute crate fails with errors like:

"_version_set", referenced from:
    fastly::http::response::handle::ResponseHandle::set_version::h234bdb33f8878476 in libfastly-XXXX.rlib
"_body_new", referenced from:
    fastly::http::body::Body::new::hYYYY in libfastly-XXXX.rlib
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1
error: could not compile `fastly-blossom` (bin "fastly-blossom" test)

The error appears during cargo test even if none of your tests actually call Fastly SDK code — cargo still tries to compile and link the entire binary as a test target.

This has a nasty consequence: any #[cfg(test)] mod tests { ... } block inside a file compiled into the binary crate is effectively dead code. It never runs via cargo test because cargo can't link the test binary. Developers add tests, the compiler accepts them, they're visible in the source tree — but they never execute. Tests that were meant to regression-guard behavior silently become documentation that rots.

Context / Trigger Conditions

• Fastly Compute Rust project with fastly = "0.11.x" (or similar) as a dependency
• The crate has both src/main.rs and src/lib.rs OR only src/main.rs
• cargo test fails at link time with _version_set / _body_new / _req_send undefined
• cargo check --target wasm32-wasip1 succeeds
• cargo check (native) succeeds (library code compiles, just can't link the binary)
• You added tests in src/admin.rs, src/blossom.rs, src/metadata.rs, or any file that's mod-included from src/main.rs but NOT from src/lib.rs

Root cause

Fastly's Rust SDK (fastly crate) is designed exclusively for wasm32-wasip1. Its public API calls unsafe FFI functions (_version_set, _req_send, _body_new, etc.) that the Fastly Compute runtime provides at execution time inside the POP. On a native host, the rustc compiler still compiles the library crate, but the linker can't resolve those FFI symbols because libfastly-native doesn't exist.