Skip to content

Maintenance: remove require from Tracer provider #2555

Closed
@dreamorosi

Description

@dreamorosi

Summary

After we launched v2 with ESM support, customers found some friction (#2523, #2290, #2464) when migrating due to X-Ray SDK for Node.js being built for CJS only and Tracer using the require keyword to monkey patch the imports for the http and https modules.

Due to the Tracer's usage of the keyword, customers that forget to add the banner see Powertools for AWS mentioned in the stack trace and think that there is a bug on our side. To mitigate this, as well as remove an unnecessary usage of the require keyword we should investigate if it's possible to avoid using it.

Why is this needed?

So that it's clearer where the issue resides and

Note that this won't remove the need for the banner, since the SDK will still only support CSJ, however the error and stack trace will change from something like this:

{
"errorType": "ReferenceError",
"errorMessage": "require is not defined in ES module scope, you can use import instead",
"stack": [
"ReferenceError: require is not defined in ES module scope, you can use import instead",
" at ProviderService.captureHTTPsGlobal (file:///opt/nodejs/node_modules/@aws-lambda-powertools/tracer/lib/esm/provider/ProviderService.js:25:9)",
" at new Tracer (file:///opt/nodejs/node_modules/@aws-lambda-powertools/tracer/lib/esm/Tracer.js:122:27)",
" at (/infra/src/pipeline/config/lambda-fns/common/powertools.ts:24:16)",
" at ModuleJob.run (node:internal/modules/esm/module_job:222:25)",
" at async ModuleLoader.import (node:internal/modules/esm/loader:323:24)",
" at async _tryAwaitImport (file:///var/runtime/index.mjs:1008:16)",
" at async _tryRequire (file:///var/runtime/index.mjs:1057:86)",
" at async _loadUserApp (file:///var/runtime/index.mjs:1081:16)",
" at async UserFunction.js.module.exports.load (file:///var/runtime/index.mjs:1119:21)",
" at async start (file:///var/runtime/index.mjs:1282:23)"
]
}

to this:

{"errorType":"Error","errorMessage":"Dynamic require of \"util\" is not supported","stack":["Error: Dynamic require of \"util\" is not supported","    at file:///var/task/index.mjs:11:9","    at node_modules/cls-hooked/context.js (file:///var/task/index.mjs:270:16)","    at __require2 (file:///var/task/index.mjs:14:50)","    at node_modules/aws-xray-sdk-core/dist/lib/context_utils.js (file:///var/task/index.mjs:1862:15)","    at __require2 (file:///var/task/index.mjs:14:50)","    at node_modules/aws-xray-sdk-core/dist/lib/aws-xray.js (file:///var/task/index.mjs:7641:24)","    at __require2 (file:///var/task/index.mjs:14:50)","    at node_modules/aws-xray-sdk-core/dist/lib/index.js (file:///var/task/index.mjs:7947:22)","    at __require2 (file:///var/task/index.mjs:14:50)","    at file:///var/task/index.mjs:8924:40"]}

Which will help customers better pinpoint the issue.

Which area does this relate to?

Tracer

Solution

Test if it's possible to remove the hardcoded require in the packages/tracer/src/ProviderService.tsfile and lettsc` convert it based on the build mode. Then, if this is successful, test that the X-Ray SDK for Node.js can still monkey patch the import even when using ESM.

Acknowledgment

Future readers

Please react with 👍 and your use case to help us understand customer demand.

Metadata

Metadata

Assignees

Labels

completedThis item is complete and has been merged/shippedinternalPRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.)tracerThis item relates to the Tracer Utility

Type

No type

Projects

Status

Shipped

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions