Translate a sampling.priority tag set to a positive value to forceKeep

[mcculls]

What Does This Do

Translate a sampling.priority tag set to a positive value to forceKeep, overriding any locked sampling priority

Motivation

Since 1.34.0 sampling.priority tags were translated to setSamplingPriority but this won't override a previously locked sampling decision. When the sampling.priority tag has a positive value we now translate that to forceKeep to ensure the trace segment is kept regardless of any previous sampling decision.

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Add your completed PR to the merge queue by commenting /merge. You can also:
  • Customize the commit message associated with the merge with /merge --commit-message "..."
  • Remove your PR from the merge queue with /merge -c
  • Skip all merge queue checks with /merge -f --reason "reason"; please use this judiciously, as some checks do not run at the PR-level (note: the PR still needs to be mergeable, this will only skip the pre-merge build)
  • Get more information in this doc

Jira ticket: APMS-19721

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	13.98 s	13.90 s	[-0.1%; +1.2%] (no difference)
startup:insecure-bank:tracing:Agent	12.93 s	12.95 s	[-0.8%; +0.5%] (no difference)
startup:petclinic:appsec:Agent	16.28 s	16.80 s	[-7.4%; +1.2%] (no difference)
startup:petclinic:iast:Agent	16.28 s	16.86 s	[-7.7%; +0.8%] (no difference)
startup:petclinic:profiling:Agent	16.77 s	16.77 s	[-0.9%; +1.0%] (no difference)
startup:petclinic:sca:Agent	16.83 s	16.72 s	[-0.4%; +1.7%] (no difference)
startup:petclinic:tracing:Agent	15.64 s	16.02 s	[-6.5%; +1.8%] (no difference)

Commit: 6e7ee5c3 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[dougqh]

[Claude Code review]

The fix looks correct — routing positive sampling.priority values through forceKeep() instead of setSamplingPriority() is the right approach and makes it consistent with how manual.keep already behaves.

However, there is no test covering the specific regression case this PR is meant to fix. Please add a test to TagInterceptorTest (or equivalent) that pins the following scenario:

1. Create a span with a propagated USER_DROP context (simulating upstream inheritance of x-datadog-sampling-priority: -1)
2. Confirm the sampling priority is locked at -1
3. Call setTag("sampling.priority", 2) (i.e. a positive value)
4. Assert that forceKeep is now true and the span would be kept

Without this, the exact silent-failure case from the original bug is not pinned and could regress undetected.

[mcculls]

Test is coming - that's why this is still in draft ;)

[dd-octo-sts]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-06-10 20:14:13 UTC ℹ️ Start processing command /merge

---

2026-06-10 20:14:18 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-06-10 21:18:10 UTC ℹ️ MergeQueue: This merge request was merged