feat(aws-serverless): Replace OTel Lambda instrumentation with handler redirection#22079
Open
andreiborza wants to merge 14 commits into
Open
feat(aws-serverless): Replace OTel Lambda instrumentation with handler redirection#22079andreiborza wants to merge 14 commits into
andreiborza wants to merge 14 commits into
Conversation
…r redirection Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
size-limit report 📦
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 2d5a898. Configure here.
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
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.

What
Replaces the vendored
@opentelemetry/instrumentation-aws-lambda(module patching viaInstrumentationBase+ import-in-the-middle) with handler redirection.The idea is that the AWS runtime reads
_HANDLERonly after all--import/--requirepreloads (and thusSentry.init()) have run. So during init, theAwsLambdaintegration points_HANDLERat a Sentry shim and stores the original value inSENTRY_ORIGINAL_HANDLER. The runtime then loads the shim instead of the user's handler; the shim resolves the original handler with the same rules as the runtime, wraps it with the existing span logic andwrapHandler, and re-exports it.sequenceDiagram participant Preload as Node.js preload<br/>(--import .../awslambda-auto) participant RIC as Lambda runtime participant Shim as Sentry shim<br/>(run-lambda-handler.mjs) participant User as User handler module Note over Preload: Sentry.init() Preload->>Preload: SENTRY_ORIGINAL_HANDLER = "index.handler"<br/>_HANDLER = ".../run-lambda-handler.handler" RIC->>Shim: reads _HANDLER, await import() Shim->>User: resolves SENTRY_ORIGINAL_HANDLER,<br/>require() for CJS / import() for ESM User-->>Shim: original handler Shim-->>RIC: exports wrapped handler<br/>(span logic + wrapHandler, streaming symbols preserved) loop every invocation RIC->>Shim: wrapped handler(event, context) Shim->>User: original handler(event, context) User-->>Shim: result Shim-->>RIC: result (span ended, events flushed) endBecause the shim wraps the handler value (whatever the export resolves to), this also covers wrapped (e.g. middy), re-exported and streaming handlers. Behavior is unchanged (same spans, attributes, origins, mechanisms), verified by the unchanged SAM e2e assertions (Node 18/20, layer and npm install methods) and against a real Lambda function. Datadog (redirect handler) and New Relic (wrapper handler) use the same approach in their layers.
Why not orchestrion
The issue proposed orchestrion, but it does not fit the Lambda case:
node_modules; the handler is an arbitrary user file resolved from_HANDLER.middy(...),awslambda.streamifyResponse(...), re-exports and bundled output.Closes: #20908