Metadata in WASM causes unstable package hash

[jdno]

Version

$ fastly version
Fastly CLI version v10.8.0 (8b3c0372)
Built with go version go1.21.5 linux/amd64 (2024-02-06)
Viceroy version: viceroy 0.5.1

What happened

Running fastly compute build twice changes the package hash without any changes to the code.

$ fastly compute build &>/dev/null && sha1sum pkg/compute-static.tar.gz
6b2b8267658b1ae8e5d2a88ccdd18dd2ceab79cf  pkg/compute-static.tar.gz

$ fastly compute build &>/dev/null && sha1sum pkg/compute-static.tar.gz
7477189702c788d9895cc11d455a2060b50f79b3  pkg/compute-static.tar.gz

I've reported this issue in the past in #743, but back then the problem was how the package was gzip'd. Now, the problem seems to be the metadata that has been added in #1016. For Rust, the metadata contains the heap size during the build. This is not stable, not even on the same machine.

{
  "build_info": {
    "mem_heap_alloc": 2891104
  }
}

Just as in #743, this is a problem for us since we deploy our Compute@Edge service using Terraform from multiple machines. To ensure the package is up-to-date locally, we rebuild it as part of terraform plan. The unstable hash causes Terraform to redeploy the service every time, even though nothing about the code has actually changed.

Disabling metadata works around this issue:

fastly compute build --metadata-disable

That is fine for now, but I feel a bit uncomfortable having to opt-out of a new feature just because it breaks our change detection. If it was stable, it might actually allow us to enforce consistent versions of the Rust compiler and the CLI across developers.

It's also unfortunate that it does not seem to be possible to configure the metadata per repository. fastly config metadata --disable-build is globally applied on the local machine. If another developer checks out the repository on their machine, they'd have to run this as well. It would be helpful if [wasm-metadata] was read from fastly.toml in each project, and not the per-user configuration on each machine.

Happy to provide more information on both our process or setup if it helps. 🙂

[Integralist]

👋🏻

Thanks for raising this @jdno

As you mentioned, fastly compute build --metadata-disable would be the workaround until we can figure out the best approach to this issue.

I'm going to raise this internally, and I'll provide feedback here once we know more.

Thanks again.

[Integralist]

Closing this issue as fixed.

https://github.com/fastly/cli/releases/tag/v10.8.1

[jdno]

Thanks for the quick turnaround! Looks good, so we'll enable metadata collection again. :)

[Integralist]

Thanks @jdno

Any other issues, then just let us know 👍🏻