Merged
Conversation
Internal Lambda extensions must be registered during the Lamba lifecycle Init phase, which ends when the runtime calls Next to await the first event. Since the `Extension::run` function both registers and executes the extension, there was previously no way for the runtime to determine that all internal extensions have been registered and that it's safe to proceed to the Invoke lifecycle phase. This change introduces an `Extension::register` method that registers the extension and begins any logs/telemetry handlers. It then returns a new `RegisteredExtension` abstraction that can be used to invoke the extension's run loop concurrently with the runtime's run loop. This change maintains backward compatibility by having the existing `Extension::run` method perform both steps. External Lambda extensions can use either API, and internal extensions should use the new API. Resolves aws#743.
ramosbugs
commented
Dec 2, 2023
| } | ||
|
|
||
| /// An extension registered by calling [`Extension::register`]. | ||
| pub struct RegisteredExtension<E> { |
Contributor
Author
There was a problem hiding this comment.
This new type seemed unavoidable since Extension::register has to pass ownership of all the logging and telemetry fields to the spawned background tasks. These are the remaining fields to be used in the invoke phase.
Contributor
|
This is great, thanks for the changes! Do you mind creating an example in the |
Contributor
Author
|
The cargo lambda deploy
cargo lambda invoke extension-internal-flush --data-example sqs-event-obj --verbose --remoteThis produced the following CloudWatch logs showing both the runtime and extension behaving as expected: |
This was referenced May 2, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Internal Lambda extensions must be registered during the Lamba lifecycle Init phase, which ends when the runtime calls Next to await the first event. Since the
Extension::runfunction both registers and executes the extension, there was previously no way for the runtime to determine that all internal extensions have been registered and that it's safe to proceed to the Invoke lifecycle phase.This change introduces an
Extension::registermethod that registers the extension and begins any logs/telemetry handlers. It then returns a newRegisteredExtensionabstraction that can be used to invoke the extension's run loop concurrently with the runtime's run loop.This change maintains backward compatibility by having the existing
Extension::runmethod perform both steps. External Lambda extensions can use either API, and internal extensions should use the new API.Resolves #743.
By submitting this pull request