chore: upgrade dd-trace to v4.50.0

[nhulston]

What does this PR do?

Upgrades dd-trace to v4.50.0

Motivation

Load in new span pointer features: DataDog/dd-trace-js#4875

Testing Guidelines

Additional Notes

Types of Changes

• Bug fix
• New feature
• Breaking change
• Misc (docs, refactoring, dependency upgrade, etc.)

Check all that apply

• This PR's description is comprehensive
• This PR contains breaking changes that are documented in the description
• This PR introduces new APIs or parameters that are documented and unlikely to change in the foreseeable future
• This PR impacts documentation, and it has been updated (or a ticket has been logged)
• This PR's changes are covered by the automated tests
• This PR collects user input/sensitive content into Datadog
• This PR passes the integration tests (ask a Datadog member to run the tests)

[purple4reina]

Just as an aside. What's the point in checking the layer size if we're just gonna keep upping the limit?

[nhulston]

Great question, I'm not sure. I guess to make sure we don't accidentally increase the size significantly without realizing?

[purple4reina]

Did we investigate why this tag moved from what looks like the inferred span to the invocation span?

[nhulston]

At the time of creating #584
I still had the issue of not being able to update the snapshots. So I added the original lines manually, and I must have put them in the wrong place even though the tests still passed.

It seems like they should be in the invocation span, not the inferred span.

[purple4reina]

I disagree. I think it should be on the inferred span since for an api.gateway span, that's where the idea of the routing is happening. Can we run these again and confirm where these tags are actually being added? This is the only trace out of all the test invocates in which it's been moved.

[nhulston]

The code that sets the http.route tags is here:

datadog-lambda-js/src/trace/trigger.ts

Lines 299 to 318 in 56965ac

	if (event.resource) {
	httpTags["http.route"] = event.resource;
	}
	return httpTags;
	}
	if (eventType.isAPIGatewayEventV2(event)) {
	const requestContext = event.requestContext;
	httpTags["http.url"] = requestContext.domainName;
	httpTags["http.url_details.path"] = requestContext.http.path;
	httpTags["http.method"] = requestContext.http.method;
	if (event.headers?.Referer) {
	httpTags["http.referer"] = event.headers.Referer;
	}
	if (event.routeKey) {
	// "GET /my/endpoint" => "/my/endpoint"
	const array = event.routeKey.split(" ");
	httpTags["http.route"] = array[array.length - 1];
	}
	return httpTags;

If you backtrack the call stack, it starts at onStartInvocation and stores the result in this.triggerTags, so at least according to the code, we are setting the tags on the Lambda span -- not the API GW inferred span.

More info: https://datadoghq.atlassian.net/browse/SVLS-5779

But maybe we should also be adding the http.route tags to the inferred span?

[purple4reina]

Did we figure out why this was removed?

[nhulston]

Not sure. Looks like it's just removed on the inferred span, but not the aws.lambda spans.

[purple4reina]

Okay, that sounds fine then. I think it'll be important to make sure they remain on the aws.lambda span even if they're removed from the inferred span.