[SiddhithaBhoopathy]

What does this PR do?

Keeps the sampling priority numeric in SpanContextWrapper.fromTraceContext.

fromTraceContext was converting sampleMode to a string ("2", "-1") before passing it to DatadogSpanContext. dd-trace only injects x-datadog-sampling-priority when the priority is an integer (text_map.js _injectSamplingPriority), and only emits the _sampling_priority_v1 metric when it is a number (span_format.js). Because child spans share the parent's _sampling object and the priority sampler skips contexts that already have a priority, the string sticks for the whole trace and the sampling decision is dropped downstream.

Motivation

Escalation SLES-3080: an API Gateway custom authorizer's sampling decision is not preserved by the integration Lambda. With no Datadog/W3C headers on the request, the authorizer falls back to X-Ray (USER_KEEP/USER_REJECT), injects _datadog without x-datadog-sampling-priority, and the integration Lambda (extract order datadog,tracecontext) re-samples independently. The customer confirmed that normalizing the priority to a number in the authorizer restores the header and preserves the upstream decision in all keep/reject × success/error cases.

Testing Guidelines

• Added a regression test asserting fromTraceContext produces an integer priority for USER_KEEP, USER_REJECT, AUTO_KEEP and AUTO_REJECT.
• Updated existing assertions that expected the string priority (span-context-wrapper.spec.ts, xray-service.spec.ts, custom.spec.ts, extractor.spec.ts, sns.spec.ts, sqs.spec.ts, sns-sqs.spec.ts).
• Updated the cjs-custom-extractor integration log snapshot: its spans now include "_sampling_priority_v1": 1, matching every other case (e.g. cjs-capture-payload). Before this fix, the custom-extractor case was the only one exported without a sampling priority, which is the bug itself showing up in the existing goldens.

Additional Notes

Affected paths (all callers of fromTraceContext):

• X-Ray fallback (XrayService.extract)
• AWSTraceHeader with Datadog-injected IDs (XrayService.extraceDDContextFromAWSTraceHeader)
• Custom trace extractors (CustomTraceExtractor)

Regression introduced in #429 (W3C support). The TraceContext.sampleMode type and the sampleMode(): number getter already expect a number.

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)

[datadog-datadog-us1-prod]

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 8f15251 | Docs | Give us feedback!}

[ojproductions]

Hi @SiddhithaBhoopathy this change looks pretty straightforward and should work fine. I copied your changes into #854 to run the ci. Pending that, should be good to merge.

[ojproductions]

@lucaspimentel asking since you've been working on sampling recently: would changing the type of sampling-priority (string -> number) break anything?

[datadog-datadog-us1-prod]

More details

Keeping sampling priorities numeric matches the context type contract and dd-trace’s propagation requirements. The completed static review found no reportable regressions across the four sampling modes.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit 8f15251}

[lucaspimentel]

@ojproductions

asking since you've been working on sampling recently: would changing the type of sampling-priority (string -> number) break anything?

Yes, sampling priority values must be integers.