-
Notifications
You must be signed in to change notification settings - Fork 348
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support internal Lambda extensions #744
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 awslabs#743.
} | ||
|
||
/// An extension registered by calling [`Extension::register`]. | ||
pub struct RegisteredExtension<E> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
This is great, thanks for the changes! Do you mind creating an example in the |
The cargo lambda deploy
cargo lambda invoke extension-internal-flush --data-example sqs-event-obj --verbose --remote This produced the following CloudWatch logs showing both the runtime and extension behaving as expected:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
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 newRegisteredExtension
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 #743.
By submitting this pull request