serverless/serverless

Long service names tend to crash deploys

Open

#7,056 创建于 2019年12月5日

在 GitHub 查看
 (15 评论) (2 反应) (0 负责人)JavaScript (46,915 star) (5,734 fork)batch import
breakingbug/designcat/deploymentcat/designdeprecationgood first issuehelp wanted

描述

I've named my service test-api-gateway-provisioned-concurrency, then stack creation succeed but update failed with:

 An error occurred: IamRoleLambdaExecution - 1 validation error detected: Value 'test-api-gateway-provisioned-concurrency-dev-us-east-1-lambdaRole' at 'roleName' failed to satisfy constraint: Member must have length less than or equal to 64 (Service: AmazonIdentityManagement; Status Code: 400; Error Code: ValidationError; Request ID: 4eee3989-ad51-4d8b-a104-d1e632e4bf22).

I think there's need to be set upfront limit for service name, and then there should be ensured not other resource names are generated too long cause that.

Fixing that seems not trivial though, as also length of stage and region influences that.


Solution proposal:

  • Restrict service name length to max 20 chars, additionally restrict format to ^[a-z][a-z0-9]*(?:-[a-z0-9]+)*$
  • Restrict stage name length to max 11 chars (and ensure it's valid for APIGateway), additionally restrict format to ^[a-z][a-z0-9]*(?:-[a-z0-9]+)*$ In v3 check manually if service name and stage match the format, and show deprecation if they do not.

In v4 configure pattern into the schema validation

Having above ensured we may design all resource names around that (knowing that prefix won't be longer that 32 chars, we may ensure that eventual postfix won't exceed the limit)

For cases where expected names needs to be quite short (e.g. there's implied 32 chars limit) I believe we should use hashes.

贡献者指南