Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lambda version is not updated when a layer from the same stack has code changes #8053

Closed
pwithams opened this issue Aug 6, 2020 · 3 comments · Fixed by #8066
Closed

Lambda version is not updated when a layer from the same stack has code changes #8053

pwithams opened this issue Aug 6, 2020 · 3 comments · Fixed by #8066

Comments

@pwithams
Copy link
Contributor

pwithams commented Aug 6, 2020

Description

When updating the code for a layer that a lambda in the same stack uses, a new layer version is updated, and the $LATEST lambda version is updated, but no new lambda numeric version is created that points to the new layer version.

It appears this is very similar to this previous issue: #4510

Every deploys "successfully" but when the versioned lambda stack output arn is referenced the version is unchanged and therefore still points to an old layer.

My guess is that looking at https://github.com/serverless/serverless/blob/master/lib/plugins/aws/package/compile/functions/index.js#L434 and the PR mentioned above the lambda version logical id is generated using the lambda source and the lambda config data. However, when using layers as described in the documentation (see example below) the layer is just a string ref to another cloudformation resource and therefore will not change unless the layer resource name is changed.

Example serverless.yml (from documentation)

https://www.serverless.com/framework/docs/providers/aws/guide/layers/

layers:
  test:
    path: layer
functions:
  hello:
    handler: handler.hello
    layers:
      - { Ref: TestLambdaLayer }

Proposed fix

If this is a bug rather than just misunderstanding of how layers within the same stack should be used, then I will submit a PR that includes the timestamped lambda layer zip S3 path so that the logical id will change each time a new layer zip is uploaded, similar to how #4510 was handled.

@medikoo
Copy link
Contributor

medikoo commented Aug 6, 2020

@pwithams thanks for reporting.

There are known issues in how we calculate lambda version hash (see also: #7822)

PR that fixes that would be very welcome!

@pwithams
Copy link
Contributor Author

I've submitted a PR for this issue. I couldn't replicate #7822 consistently so I instead added a test that I think simulates the conditions described.

@orr-levinger
Copy link

This still happens.. using version 2.7.0 the plugin created version N in the lamda layers but didnt update the lambda itself toy use the version..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants