Deployment error occurs from v4.4.4 without any changes

[nikon-h-mizukami]

Issue description

In a situation where serverless.yml and source code have not been changed, the following error occurs from v4.4.4 and deployment is not possible.
Up to v4.4.3, I was able to deploy without any problems.
I am using v6.0.0 of dotEnv, but there seems to be a problem with compatibility with v4.4.4.
Please confirm.

[Container] 2024/10/04 07:50:47.055066 Running command sls deploy --region $AWS_REGION --stage $AWS_STAGE

• Initializing

✖ Error: Cannot resolve '${cf:application.DefaultSecurityGroup}' variable at 'functions.2.ApplicationRegister.vpc.securityGroupIds.1'. No value is available for this variable, and no default value was provided. Please check your variable definitions or provide a default value.
at _ResolverManager.resolve (file:///root/.serverless/releases/4.4.4/package/dist/sf-core.js:655:55913)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async #handlePlaceholderNode (file:///root/.serverless/releases/4.4.4/package/dist/sf-core.js:655:54343)
at async file:///root/.serverless/releases/4.4.4/package/dist/sf-core.js:655:52335
at async processNodeAndHandleCompletion (file:///root/.serverless/releases/4.4.4/package/dist/sf-core.js:655:43086)

For help, try the following:
• Run the command again with the "--debug" option
• Run "serverless support"
• Review the docs: https://www.serverless.com/framework/docs/

Context

N/A

[czubocha]

Hi @nikon-h-mizukami, thanks for reporting this issue.

Please note that starting from v4, the Serverless Framework has built-in support for .env files, so using the dotEnv plugin is no longer required. You can safely remove it from your configuration if that’s relevant to your setup.

To help us investigate further, could you provide more details? Specifically, it would be helpful if you could share a reproducible example of your serverless.yml configuration.

In the meantime, you can pin the working version in your serverless.yml file to avoid disruption while we look into the issue. You can find more information about pinning a version here: Pinning a version.

[czubocha]

Since we haven't received any updates, I'll be closing this issue for now. If you're still experiencing the problem, please feel free to reopen the issue with additional details or a reproducible example of your serverless.yml configuration. This will help us investigate further.

Thanks for your report and for using Serverless!

[nikon-h-mizukami]

Hi @czubochas, sorry for the late reply.
Even in v4.4.7, the problem is not inherited, and the serverless.yml that causes an error and the yml that succeeds are stored in an excel sheet.
Also includes error logs.

I would appreciate it if you could let me know if there are any files that are missing in addition to those required for the investigation.

serverless.xlsx

[nikon-h-mizukami]

It seems like I don't have permission to reopen, how can I do so?
Please reopen there if possible.

[czubocha]

Thanks for sharing the details. We’ll review them and get back to you.

[nikon-h-mizukami]

@czubocha
The issue has been left closed. What's going on? Since I'm paying for it, please explain the cause and take action.

[czubocha]

Hi @nikon-h-mizukami, could you test this issue with the latest Serverless version (4.4.16) and share the results? Additionally, does the issue persist if you limit your configuration to only one function? Based on your logs and description, it seems the root cause might be related to CloudFormation API throttling. In v4, variable resolution is performed in parallel, which could be a contributing factor. If this is the case, you might try increasing the maximum retry attempts for the underlying AWS SDK by setting the AWS_MAX_ATTEMPTS environment variable (default is 3).

[nikon-h-mizukami]

Hi @czubocha ,we have confirmed that the issue has been resolved in v4.4.16.
I'll check AWS_MAX_ATTEMPTS if I run into any issues in the future.
Thank you.