archive not being able to determine value

[tomasbackman]

Terraform CLI and Provider Versions

Terraform v1.5.7

• provider registry.terraform.io/hashicorp/archive v2.7.1
• provider registry.terraform.io/hashicorp/google v7.5.0
• provider registry.terraform.io/hashicorp/google-beta v7.5.0

Terraform Configuration

Copied and edited relevant config  
with providers above, the below code should make it reproducible)


### Module: cloud_function_automation
variable "function_name" {
  description = "The name also need to correspond to a folder with the scripts for the function."
  type        = string
}
variable "function_bucket" {
  description = "The bucket where the functions should be stored in gcp."
  type        = string
}
# Create a zip file from function folder
resource "archive_file" "function_zip" {
  type = "zip"
  # The folder/files source are located in the gitlab job workdir
  #   terraform root is in <gitlab job workdir>/.terraform/modules/<module_name>/
  source_dir  = "${path.root}/../../../${var.function_name}"
  output_path = "${path.root}/${var.function_name}.zip"
}
# Upload zip file to given functions bucket
resource "google_storage_bucket_object" "function_obj" {
  name   = "${path.root}/${var.function_name}.zip"
  bucket = var.function_bucket
  source = resource.archive_file.function_zip.output_path
}

### Config main
locals {
envs = ["Sandbox"]
}

module automation {
  for_each = toset(local.envs)
  source          = cloud_function_automation
  function_name   = "my_function_folder"
  function_bucket = "my_bucket"
}

Expected Behavior

Zip file created and uploaded to gcs bucket

Actual Behavior

terraform plan worked fine,
but the terraform apply gives several (for all archive outputs .id, .output_base64sha256, output_base64sha512 etc .:

Error: Provider returned invalid result object after apply
│
│ After the apply operation, the provider still indicated an unknown value
│ for module.my_mod["sandbox"].archive_file.function_zip.id. All
│ values must be known after apply, so this is always a bug in the provider
│ and should be reported in the provider's own repository. Terraform will
│ still save the other known object values in the state.

Steps to Reproduce

1. terraform apply

How much impact is this issue causing?

High

Logs

No response

Additional Information

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[tomasbackman]

@rainkwan @austinvalle @SBGoods
As the 3 biggest non-bot contributors last 12 months (with total 8 commits ... ) Do any of you have any idea if there are anyone maintaining or looking in this repo/product nowadays and/or helping with bugs (like this).
Or suggestions on how to get some attention?

[austinvalle]

Hey there @tomasbackman 👋🏻 , thanks for raising the issue and sorry you're running into trouble here.

To answer your question unrelated to this issue:

As the 3 biggest non-bot contributors last 12 months (with total 8 commits ... ) Do any of you have any idea if there are anyone maintaining or looking in this repo/product nowadays and/or helping with bugs (like this).
Or suggestions on how to get some attention?

I'm on the maintaining team that owns this provider, and we do monitor/triage issues that come in on a monthly basis. There's no ongoing feature development at the moment in archive (or has there been in the past year), but if there are any bugs we can fix we try to prioritize them appropriately. Since there's no new development, we don't really run across many new bugs that aren't variations of known quirks of the provider (most of which we can't actually solve without breaking a ton of configurations 😔 ).

---

On to your specific issue, this one is interesting because I'm actually not sure how it's possible the archive provider could produce that error from Terraform: After the apply operation, the provider still indicated an unknown value for module.my_mod["sandbox"].archive_file.function_zip.<computed_attribute>. That implies that the archive provider is both:

• Not producing a diagnostic (like the output path can't be written to, or the archive failed to be created)
• Not setting any of it's computed attributes (keeping them as unknown, from the plan)

The actual code of the provider is pretty simple:

terraform-provider-archive/internal/provider/resource_archive_file.go

Lines 252 to 306 in ea52114

	func updateModel(ctx context.Context, model *fileModel) diag.Diagnostics {
	var diags diag.Diagnostics
	outputPath := model.OutputPath.ValueString()
	outputDirectory := path.Dir(outputPath)
	if outputDirectory != "" {
	if _, err := os.Stat(outputDirectory); err != nil {
	if err := os.MkdirAll(outputDirectory, 0755); err != nil {
	diags.AddError(
	"Output path error",
	fmt.Sprintf("error creating output path: %s", err),
	)
	return diags
	}
	}
	}
	if err := archive(ctx, *model); err != nil {
	diags.AddError(
	"Archive creation error",
	fmt.Sprintf("error creating archive: %s", err),
	)
	return diags
	}
	// Generate archived file stats
	fi, err := os.Stat(outputPath)
	if err != nil {
	diags.AddError(
	"Archive output error",
	fmt.Sprintf("error reading output: %s", err),
	)
	return diags
	}
	model.OutputSize = types.Int64Value(fi.Size())
	checksums, err := genFileChecksums(outputPath)
	if err != nil {
	diags.AddError(
	"Hash generation error",
	fmt.Sprintf("error generating hashed: %s", err),
	)
	return diags
	}
	model.OutputMd5 = types.StringValue(checksums.md5Hex)
	model.OutputSha = types.StringValue(checksums.sha1Hex)
	model.OutputSha256 = types.StringValue(checksums.sha256Hex)
	model.OutputBase64Sha256 = types.StringValue(checksums.sha256Base64)
	model.OutputSha512 = types.StringValue(checksums.sha512Hex)
	model.OutputBase64Sha512 = types.StringValue(checksums.sha512Base64)
	model.ID = types.StringValue(checksums.sha1Hex)
	return diags
	}

, and I don't see any code paths where it wouldn't produce a more detailed error 🤔

I might need some more information from you to track down where exactly the problem is, as I tried a local run of the example config you gave with all the same release versions and was able to successfully apply. I documented everything I ran over in this repo:

• https://github.com/austinvalle/tf-archive-issue-468

As of right now, I'm wondering if this could be a bug either in our SDKs (terraform-plugin-framework) or terraform itself (maybe related to modules? 🤷🏻 ). Some things that you could help me with to continue debugging are:

• Perhaps providing a more localized example that I can recreate the bug with (for example, can you modify the repo code I sent to produce the error? Does it already return an error for you trying to run it?
• Could you give me more information about the entire terraform apply run that produced the error? Perhaps a TF_LOG=trace in a GitHub gist? (please review it prior to posting to ensure there is no sensitive information 😆)
• Maybe more information about the modules/configuration that is producing the error.
• If you're able to try this on the latest version of Terraform v1.13.x, that also might just skip past any future debugging we need to do, although I am desperately curious how this error could be produced 😅

[tomasbackman]

@austinvalle Thank you for the answer!
Im having a "long weekend vacation" from tomorrow and I need to finish some other stuff that have turned up, but I am happy to try to provide more info here during next week.