Phantom Compute service changes caused by `source_code_hash` discrepancies

[jwadolowski]

Overview

Last week I noticed that the provider keeps reporting a pending change even though the Compute binary remains unchanged. No matter how many times you apply the change, the result is always identical:

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.compute.fastly_service_compute.foo will be updated in-place
  ~ resource "fastly_service_compute" "foo" {
      ~ active_version  = 112 -> (known after apply)
      ~ cloned_version  = 112 -> (known after apply)

      ~ package {
          ~ source_code_hash = "1c333507c41b9368bab1f27660af93adb0b08f916dc68abe06c08d0db1e114227fdc8556d0dae083fb833eb3a48a02ddfe5c3fee277cbc063661306d8842b708" -> "1f29ce557e72df67d5ad8afdf1843aab554fc9ab3a7296c94648d0307551265153df0880e03925a14563d7659135c5bf7489efb8a46cdbc18e6937e18ff5dfdb"
            # (2 unchanged attributes hidden)
        }

        # (3 unchanged blocks hidden)
    }

The API service receives only the binary (see here) and calculates both files_hash and hashsum (SHA512 of the binary) internally. However, the files_hash calculation (used for source_code_hash comparison later) apparently differs from the Terraform provider's calculation method:

terraform-provider-fastly/fastly/data_source_package_hash.go

Lines 151 to 164 in 6ede21c

	func getFilesHash(contents map[string]*bytes.Buffer) (string, error) {
	keys := make([]string, 0, len(contents))
	for k := range contents {
	keys = append(keys, k)
	}
	sort.Strings(keys)
	h := sha512.New()
	for _, fname := range keys {
	if _, err := io.Copy(h, contents[fname]); err != nil {
	return "", err
	}
	}
	return fmt.Sprintf("%x", h.Sum(nil)), nil
	}

Example

1. Starting point: the most recent version of my Compute service is 109
2. The binary I'm about to deploy looks as follows:

$ sha512sum ../compute/src/pkg/foo.tar.gz
4a56a0b5deec7c3002606e3366f2b9215aff59443b8a406b388733eb61c5745098261b233a89bb42cdd2b0a605a545d1657174b5ba4046818729490ca2b58f46  ../compute/src/pkg/foo.tar.gz

3. I deployed the service using v8.5.0 of the provider, which created version 110 (irrelevant attributes removed):

{
  "created_at": "2025-12-01T12:26:47Z",
  "id": "9elkprpciT1ZxuvOaNC9f0",
  "metadata": {
    "cloned_from": "https://github.com/fastly/compute-starter-kit-go-default",
    "files_hash": "1c333507c41b9368bab1f27660af93adb0b08f916dc68abe06c08d0db1e114227fdc8556d0dae083fb833eb3a48a02ddfe5c3fee277cbc063661306d8842b708",
    "hashsum": "4a56a0b5deec7c3002606e3366f2b9215aff59443b8a406b388733eb61c5745098261b233a89bb42cdd2b0a605a545d1657174b5ba4046818729490ca2b58f46",
    "language": "go",
    "name": "foo",
    "size": 1823178
  },
  "updated_at": "2025-12-01T12:26:48Z",
  "version": 110
}

4. I then used Terraform to deploy the identical binary again (the same phantom change appeared)
5. Terraform created and activated version 111

{
  "created_at": "2025-12-01T12:34:57Z",
  "id": "qYUk3Y5fG5J2eVWSx0L0R2",
  "metadata": {
    "cloned_from": "https://github.com/fastly/compute-starter-kit-go-default",
    "files_hash": "1c333507c41b9368bab1f27660af93adb0b08f916dc68abe06c08d0db1e114227fdc8556d0dae083fb833eb3a48a02ddfe5c3fee277cbc063661306d8842b708",
    "hashsum": "4a56a0b5deec7c3002606e3366f2b9215aff59443b8a406b388733eb61c5745098261b233a89bb42cdd2b0a605a545d1657174b5ba4046818729490ca2b58f46",
    "language": "go",
    "name": "foo",
    "size": 1823178
  },
  "updated_at": "2025-12-01T12:34:57Z",
  "version": 111
}

[rcaril]

Hi @jwadolowski - thanks for reporting this issue. We'll review further and determine if this is a bug.

In the interim, can you please let us know which version of the Fastly provider you are using?

[jwadolowski]

Hi @rcaril. I tried both 8.4.0 (2nd latest) and 8.5.0 (the latest at the time of writing), and the deployment behaves exactly the same.

[rcaril]

Hi @rcaril. I tried both 8.4.0 (2nd latest) and 8.5.0 (the latest at the time of writing), and the deployment behaves exactly the same.

Got it, thanks! We'll follow up once we have findings to share.

[jwadolowski]

FYI, since both the server (Fastly API) and the client (TF provider) may require changes, I also filed a support ticket: #00564148 (can share more details there if needed).

[rcaril]

Hey @jwadolowski - can you confirm if you imported this Compute service into Terraform and / or if this behavior started occurring on it's own after an Terraform provider upgrade?

[jwadolowski]

The compute service has been managed via Terraform since its very first deployment (AFAIR ~mid-July 2025) and nothing was imported into the TF state.

A production version of the same service behaves exactly the same way.

The provider upgrade seems irrelevant in this case, as I'm quite sure I stumbled upon this before (just didn't bother to file a GH issue until yesterday).

[syphar]

this issue is happening to us too.

From our side the compute service was initially created with terraform.

My impression was that it started happening when we pushed a new source archive to fastly.

After that archive-push, all new terraform plans did output a change in the hash, even though the local archive is the same.

( also applying that non-existing change doesn't help).

My hunch (purely from the outside) would be that something changed internally in the API, and not in the TF provider. So that how the hash is calculated diverged between the provider resource and the API / fastly internals.