Invalid request provided: Updating PackageType is not supported

[gleidsonh]

I'm trying to deploy this function using an ECR image, but without success. Every time I get the error message: UPDATE_FAILED: FunctionLambdaFunction (AWS::Lambda::Function)
Resource handler returned message: "Invalid request provided: Updating PackageType is not supported"

service: service-name
useDotenv: true

provider:
  name: aws
  profile: ${env:PROFILE}
  stage: ${opt:stage, 'dev'}
  memorySize: 128
  apiGateway:
    restApiId: ${self:custom.apiGateway.${self:custom.stage}.restApiId}
    restApiRootResourceId: ${self:custom.apiGateway.${self:custom.stage}.restApiRootResourceId}
    restApiResources:
      service: ${self:custom.apiGateway.${self:custom.stage}.restApiResources}

plugins:
  - serverless-offline
  - serverless-domain-manager
  - serverless-dotenv-plugin

functions:
  function:
    image: 000000000000.dkr.ecr.us-east-1.amazonaws.com/service-name:latest

custom:
  serverless-offline:
    httpPort: 8888
  dotenv:
    path: ../../../../.env
    include:
      - REGION
      - ACCESS_KEY_ID
      - SECRET_ACCESS_KEY
      - JWT_TOKEN
  stage: ${self:provider.stage}
  apiGateway:
    prod:
      restApiId: ${env:CLIENT_PROD_REST_API_ID}
      restApiRootResourceId: ${env:CLIENT_PROD_REST_API_ROOT_RESOURCE_ID}
      restApiResources: ${env:SERVICE_PROD_REST_API_RESOURCES}
    staging:
      restApiId: ${env:CLIENT_STAGING_REST_API_ID}
      restApiRootResourceId: ${env:CLIENT_STAGING_REST_API_ROOT_RESOURCE_ID}
      restApiResources: ${env:SERVICE_STAGING_REST_API_RESOURCES}
    dev:
      restApiId: ${env:CLIENT_DEV_REST_API_ID}
      restApiRootResourceId: ${env:CLIENT_DEV_REST_API_ROOT_RESOURCE_ID}
      restApiResources: ${env:SERVICE_DEV_REST_API_RESOURCES}
  domains:
    prod: ${env:CLIENT_DOMAIN_PROD}
    staging: ${env:CLIENT_DOMAIN_STAGING}
    dev: ${env:CLIENT_DOMAIN_DEV}
  customDomain:
    basePath: ""
    domainName: ${self:custom.domains.${self:custom.stage}}
    stage: "${self:custom.stage}"
    certificateName: ${env:DOMAIN_CERTIFICATE_NAME}
    createRoute53Record: false

As I understand it, there are only two values for PackageType: zip or image. But apparently I don't have access to this configuration, the serverless itself does this, correct? Am I doing something wrong or is there a possibility of a bug in the PackageType?

I'm using:
Environment: linux, node 12.22.0, framework 3.7.1 (local) 3.7.1v (global), plugin 6.1.5, SDK 4.3.2

[gleidsonh]

I found out why. There was already a function in aws of type zip, and when trying to deploy it gave the error. I needed to remove (sls remove) and then deploy (sls deploy), then it worked.

I don't know if this is a bug (serverless or CloudFormation) or if it really is meant to be. However, I don't think it's interesting to remove a function and then add it again. If by any chance it goes bad, the service may be unavailable for a while.

Please don't delete this thread as it may help others. I haven't found anything on the internet that has this solution.

[pgrzesik]

Hello @gleidsonh - this is a limitation on AWS side - if the function will be created with ZIP as package type, it cannot be later changed to Image without removing the function first and deploying it with changed package type.

[gleidsonh]

Thank you very much for your explanation.

[denis-ryzhkov]

If you switch existing Lambda function from ZipFile to ImageUri,
you will get the error "Updating PackageType is not supported".

If you don't want to remove the function from serverless.yml, deploy it,
then add the function using image, deploy it,
there is another solution, to reduce the downtime and avoid breaking references.

If you rename the function in serverless.yml,
it will automatically delete the old function and create the new one, using image,
but it will also replace the log group, DELETING the logs.

If you add DeletionPolicy: Retain to the log group
before renaming the function, and then rename the function back,
serverless will try to create this log group and fail,
so you will need to import this log group to CloudFormation to keep using it.

To address all these issues, please apply the next simpler steps:

• Open your stack in AWS Console - CloudFormation - Stacks:
  https://console.aws.amazon.com/cloudformation/home#/stacks
• Update - Edit template in designer - View in Designer - YAML
• Rename all LambdaFunction-s affected and their FunctionName-s, e.g:
  • Rename ApiLambdaFunction to Api2LambdaFunction
  • Rename service-stage-api to service-stage-api2
  • Find and rename it everywhere except file names and ApiLogGroup
  • Keeping ApiLogGroup as is is crucial to avoid it being deleted soon
• Click the "Create stack" button - the name is misleading, it will "Update stack"
• Next - Next - Next - I acknowledge IAM resources - Update stack
  • It will delete ApiLambdaFunction using ZipFile
  • It will create Api2LambdaFunction using ZipFile
  • It will not change ApiLogGroup
• Refresh the "Events" tab until the stack is UPDATE_COMPLETE
• Now deploy the updated serverless.yml having e.g. functions.api.image
  • It will delete Api2LambdaFunction using ZipFile
  • It will create ApiLambdaFunction using ImageUri
  • It will reuse ApiLogGroup

[lehmat]

For those who have too many lambdas in one stack and/or want more faster approach compared to @denis-ryzhkov more precise solution:

NOTE! This will create new log groups instead of reusing the ones already created. Those of you who want to persist the logs in same log group - You cannot do this.

This is more brutal force approach, so you should always test (like everything) in your testing environment first

1. Add IAM policy to your IAM User you are using to deny deleting log groups:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyDeletingLogGroups",
            "Effect": "Deny",
            "Action": [
                "logs:Delete*"
            ],
            "Resource": "*"
        }
    ]
}

2. Rename all of your logical names in serverless.yml:
   LambdaFunction: ${file(./serverless/function.yml)} -> LambdaFunction2: ${file(./serverless/function.yml)}
3. Deploy the serverless stack
4. Manually delete log groups when the time is right

[denis-ryzhkov]

That's really a fast and brutal approach, but wouldn't it lead to DELETE_FAILED status for the LogGroup resource, causing CloudFormation to rollback the stack update?

If in your case it is acceptable to rename the functions one-way and never reuse the old log groups, just keep them not deleted, then you can just add DeletionPolicy: Retain - either via AWS Console or in the latest serverless.yml still using no images by adding resources: extensions: YourLogGroup: DeletionPolicy: Retain and deploying it before you rename the functions. This will lead to DELETE_SKIPPED status of log groups, causing no rollback of the stack update.

[lehmat]

It will enter UPDATE_COMPLETE_CLEANUP_IN_PROGRESS in CF and the DELETE_FAILED in that state will not result in rollingback. it will eventually have DELETE_FAILED in the events, but the stack will be UPDATE_COMPLETE when it is finished.

[unitypark]

Hi there, I have prepared a demo app for best practice to define lambda and cloudwatch log group and summary in readme.
It might solve your problem! https://www.linkedin.com/feed/update/urn:li:activity:7041188319786926080/

[codeyourwayup]

Yes, it solves my problem. basically, i was using regular lambada functions previously, now i changed to image-based, it gave me errors. first please delete old ones, by using sls remove.

[randal923]

I deleted the lambda function but I am still getting the same error. Do I need to delete the CloudFormation stack? wouldn't this also delete my documentDB?

[niomwungeri]

https://stackoverflow.com/questions/77284622/resource-handler-returned-message-invalid-request-provided-updating-packagety#comment139508052_77366821