Terraform-provider-aws: resource/aws_lambda_function: changing `publish` attribute doesn't publish a new version

[mewa]

Terraform Version

Terraform v0.11.5

• provider.archive v1.0.3
• provider.aws v1.13.0

Affected Resource(s)

• aws_lambda_function

Terraform Configuration Files

https://github.com/mewa/terraform-lambda-publish-bug

Expected Behavior

When updating publish attribute of aws_lambda_function, a new version should be published, even if there are no source code changes (same hash).

Actual Behavior

Only the publish attribute is changed, version is not published.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply
2. Test both aliases
   2.2 aws lambda invoke --function-name test-lambda:development --region eu-central-1 out &>/dev/null && cat out
   2.3
   aws lambda invoke --function-name test-lambda:development --region eu-central-1 out &>/dev/null && cat out
   Responses:

// development
{
   "deployEnv" : "development",
   "message" : "Latest msg",
   "version" : "$LATEST"
}

// production
{
   "deployEnv" : "development",
   "message" : "Latest msg",
   "version" : "$LATEST"
}



md5-6f0eeadc3d26b6a4007f9e5c19566125



```json
// production
{
   "deployEnv" : "production",
   "message" : "Latest msg",
   "version" : "$LATEST"
}

[mewa]

I have changed this line to include the publish changed check and verified that behaviour was as expected.

d.HasChange("publish")

[catsby]

Hey @mewa thanks for writing in. I'm not sure this is a bug or in need of a change. The publish field toggles if changes to the function should create/publish a new version. Here you are not changing the function, so I'm not convinced that changing the line mentioned would be correct.

Could you possibly elaborate on how you imagine this field to behave? Assuming you enable it and it behaves the way you describe, when or why would you then disable it?

Would a separate aws_lambda_function_version resource make more sense?

[mewa]

Hey @catsby, I have the following scenario in mind:

We're pushing a new version of a lambda (its code), which then goes on to test, staging and eventually reaches production environment.

It's natural that the function configuration will change between these stages (env vars mostly). In order to change configuration in a published function one has to publish a new version.

However, the failed versions (i.e. those that don't end up in production without changes only to configuration) hold no significance, so I would disable publishing them.
This way, when there are unforeseen complications (not caught while testing) with the new version of the function we have the assurance that we can safely revert to a previously published function.

As an added bonus, the lambda stays cleaner, because there are fewer versions littering around.

Would a separate aws_lambda_function_version resource make more sense?

In the above scenario this sounds like a good solution indeed.

[mewa]

The same behaviour is met when changing env vars - and while just updating the publish attribute may not justify a new version, I think not doing so in this case is counter-intuitive.

[catsby]

Thanks for detailing your use case! I can't say that the Terraform team will get to this anytime soon, but from your explanation and my understanding it seems reasonable.

[eistrati]

+1

I was trying to test this feature and end up here. Please let us know when this will be implemented / fixed. Thanks in advance!

[bassmanitram]

This is also the case when changing the timeout value of a function - and presumably other attributes not related to the code.

My example is an Edge Lambda originally deployed with the wrong timeout, then trying to attach it to a CloudFront distribution. CF rejected it (timeout too large) so I changed the timeout and reapplied. The timeout value of the Latest version of the function was modified but the function was not republished, so CF still received the reference to the original published version and so again failed to deploy.

[bflad]

The fix for the resource only publishing versions on function code updates has been merged and will release with version 2.50.0 of the Terraform AWS Provider, later today. Thanks to @nemreid for the implementation. 👍

Please note:

• That this resource will now use a separate PublishVersion API call, so any restrictive IAM policies for the Terraform run may require updates.
• This issue was marked for closure from the fix pull request, however the original report about only updating the publish argument from false to true not publishing a version may still be true -- if so, please open a fresh issue.

[nemreid]

This issue was marked for closure from the fix pull request, however the original report about only updating the publish argument from false to true not publishing a version may still be true -- if so, please open a fresh issue.

Although I am unsure which part of the code is responsible, I performed ad hoc testing at the time of opening the PR which confirmed this bug is fixed, and added this ticket for closing.
I just now recreated that ad hoc test and saw same-hash version published with the following plan output:

      ~ publish                        = false -> true
        source_code_hash               = "F8vNUSzCGd6e1oM7Qnlpf32tTOaaN5RPC6vk/e5h/+w="

where publish was the only thing marked for change but a version was published.
Thanks for reviewing @bflad.

[hashibot[bot]]

This has been released in version 2.50.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!