[Lambda DevX] Control Lambda Container Startup Timeout when In Lambda Debug Mode #11398
Conversation
S3 Image Test Results (AMD64 / ARM64) 2 files 2 suites 3m 36s ⏱️ Results for commit e9c6081. ♻️ This comment has been updated with latest results. |
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 1h 14m 19s ⏱️ - 19m 12s Results for commit 30d07ed. ± Comparison against base commit 8068e9d. This pull request removes 917 tests.♻️ This comment has been updated with latest results. |
| # Returns the timeout value in seconds to be enforced during lambda container startups. | ||
| # This is the value defined through LAMBDA_RUNTIME_ENVIRONMENT_TIMEOUT or the LAMBDA | ||
| # DEBUG MODE default if this is enabled. | ||
| if is_lambda_debug_timeout_for(self.function_version.qualified_arn): |
There was a problem hiding this comment.
I think we should create a follow-up docs PR and list the implications of the Lambda debug mode.
We could also add a debug log here to make the config adjustment traceable at runtime (similar for other potentially implicit config updates) 🤔 Do you think logging is helpful or verbose clutter @dfangl @dominikschubert?
There was a problem hiding this comment.
I think it's a nice idea to see those changes live. However, currently users are using debug mode very often, which might lead to being too verbose. As long as the config changes are limited to a handful, I think it is fine, once it gets too much, maybe one consolidated line of changes?
|
|
||
| class LambdaDebugConfig(BaseModel): | ||
| debug_port: Optional[int] = Field(None, alias="debug-port") | ||
| timeout_disable: bool = Field(False, alias="timeout-disable") |
There was a problem hiding this comment.
EDIT: wrong PR, migrated to the original PR in this new comment
| # Returns the timeout value in seconds to be enforced during lambda container startups. | ||
| # This is the value defined through LAMBDA_RUNTIME_ENVIRONMENT_TIMEOUT or the LAMBDA | ||
| # DEBUG MODE default if this is enabled. | ||
| if is_lambda_debug_timeout_for(self.function_version.qualified_arn): |
There was a problem hiding this comment.
I think it's a nice idea to see those changes live. However, currently users are using debug mode very often, which might lead to being too verbose. As long as the config changes are limited to a handful, I think it is fine, once it gets too much, maybe one consolidated line of changes?
* Depends on #11363
Motivation
Currently, when a Lambda function is executed in debug mode, the system increases the evaluation timeout, which works well if the debugger connects after the function handler is invoked. However, this approach fails in scenarios where the debugger needs to connect during the container's startup phase, specifically when the debugger connection code resides outside the Lambda function handler.
To address this limitation, these changes propose to automatically extend the Lambda container startup timeout when the system detects it is running in Lambda Debug Mode, and the target lambda function is being debugged on some remote port.
Changes