-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix(aws): Ensure lambda layer uses default export from ImportInTheMiddle
#12233
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
Conversation
@@ -124,7 +140,7 @@ export function makeBaseBundleConfig(options) { | |||
const bundleTypeConfigMap = { | |||
standalone: standAloneBundleConfig, | |||
addon: addOnBundleConfig, | |||
node: nodeBundleConfig, |
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.
Is node not used anywhere else? Nice!
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.
Nope, the only thing we bundled with this config on the node side is the aws lambda layer bundle
ImportInTheMiddle
ImportInTheMiddle
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.
Is there a reasonable way for us to test this? maybe with an e2e test? I realize it's maybe too much because this fix is temporary based on the upstream stuff, but I'd like to make sure this doesn't regress again with any future OTEL changes.
Yes, my plan is to add an e2e test that more or less does exactly what our layer would do. Taking a look at this right now. |
So this is a fun one:
Our lambda layer relies on one bundled Sentry SDK, which caused problems raised in #12089 and #12009 (comment). Specifically, by bundling
import-in-the-middle
code into one file, it seems like the library's way of declaring its exports conflict, causing the "ImportInTheMiddle is not a constructor" error to be thrown. While this should ideally be fixed soon inimport-in-the-middle
, for now this PR adds a small Rollup plugin to transformnew ImportInTheMiddle(...)
calls tonew ImportInTheMiddle.default(...)
to our AWS Lambda Layer bundle config.Once the fixes land upstream and we updated our dependencies accordingly, we should remove this plugin again.
I tested this locally with a reproduction that failed with the exact same error message as reported in #12089. We should add an e2e test that tests the layer (as well as the AWS Serverless SDK). I'm gonna take a look at this today and open a follow up PR.
For now, this (in combination with #12232) hopefully
fixes #12089