@sentry/aws-serverless instrumentation ineffective

[jd-carroll]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/aws-serverless

SDK Version

8.0.0

Framework Version

No response

Link to Sentry event

No response

SDK Setup

No response

Steps to Reproduce

The "0 bytes" indicates esbuild has dropped them from the bundle.

Expected Result

NA

Actual Result

NA

[jd-carroll]

@mydea I missed this in my other comment, the aws instrumentation is now completely dropped.

[Lms24]

Hey @jd-carroll just to confirm, are you using @sentry/aws-serverless directly or the Sentry AWS Lambda Layer?

I wonder what makes esbuild shake out the two AWS instrumentations. They're directly referenced in the SDK init function:

sentry-javascript/packages/aws-serverless/src/sdk.ts

Lines 63 to 97 in d651f13

	/**
	* Get the default integrations for the AWSLambda SDK.
	*/
	// NOTE: in awslambda-auto.ts, we also call the original `getDefaultIntegrations` from `@sentry/node` to load performance integrations.
	// If at some point we need to filter a node integration out for good, we need to make sure to also filter it out there.
	export function getDefaultIntegrations(_options: Options): Integration[] {
	return [...getDefaultIntegrationsWithoutPerformance(), awsIntegration(), awsLambdaIntegration()];
	}
	/**
	* Initializes the Sentry AWS Lambda SDK.
	*
	* @param options Configuration options for the SDK, @see {@link AWSLambdaOptions}.
	*/
	export function init(options: NodeOptions = {}): void {
	const opts = {
	_metadata: {} as SdkMetadata,
	defaultIntegrations: getDefaultIntegrations(options),
	...options,
	};
	opts._metadata.sdk = opts._metadata.sdk || {
	name: 'sentry.javascript.aws-serverless',
	integrations: ['AWSLambda'],
	packages: [
	{
	name: 'npm:@sentry/aws-serverless',
	version: SDK_VERSION,
	},
	],
	version: SDK_VERSION,
	};
	initNode(opts);
	}

Regardless, we'll investigate this soon. Thanks for raising!

[Lms24]

You probably shared this already in another issue but would you mind posting your Sentry.init function call again? Thanks!

[jd-carroll]

I appreciate the support on this, you guys have been real quick with turn around this issue.

I am not using the lambda layer. If I were using a lambda layer, I'd be marking all @sentry/* as external to esbuild. (so nothing would be included at all)

For completeness, here is what the esbuild output looks like if I do that:

(So that's 800kb from Sentry alone --> Honestly, that sentry is 2x the size of the lambda otherwise makes this more of a critical issue for me)

This is my Sentry.init, it is injected into the top of the generated files using inject from esbuild

import * as Sentry from '@sentry/aws-serverless';

function SentryInit() {
  const dsn = buildSentryDsn();
  if (!dsn) {
    return;
  }

  Sentry.init({
    dsn,
    tracesSampleRate: 1
  });
}

SentryInit();

And to further clarify, I am running esbuild with minify: true because that is the only way dead code elmination actually runs.

(Continuation from #11991)

While the aws instrumentation is an issue, I'd actually suggest focusing on why the other instrumentation elements are there.

I'll also point to my comment on the last issue: #11991 (comment)

TLDR: I think @sentry/node should be broken up into "node-core" and "node". "node-core" representing the composable pieces and "node" as the instantiation of those pieces. That way "aws-serverless" can just depend on "node-core". (I also do not think this would result in any breaking changes.)

[timfish]

Are you bundling to ESM or CommonJs and are the Sentry dependencies being loaded via the ESM paths?

The esbuild docs say:

The main fields setting is set to main,module. This means tree shaking will likely not happen for packages that provide both module and main since tree shaking works with ECMAScript modules but not with CommonJS modules.

Unfortunately some packages incorrectly treat module as meaning "browser code" instead of "ECMAScript module code" so this default behavior is required for compatibility. You can manually configure the main fields setting to module,main if you want to enable tree shaking and know it is safe to do so.

And both main and module set:

sentry-javascript/packages/node/package.json

Lines 20 to 21 in 1390402

	"main": "build/cjs/index.js",
	"module": "build/esm/index.js",

The docs also suggest that esbuild just doesn't support tree shaking with CommonJs.