Bump extension version to `95-next` in preparation for the v95 release.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Sonnet 4.6 <[email protected]>

## Overview
... so everyone can experiment with their own `AGENTS.md`. In a few
weeks, we will build a shared `AGENTS.md` and remove it from
`.gitignore`.

## Testing 
N/A

…function logs (#1053)

## Summary

If the function is a durable function, then add two attributes to every
log:
- `lambda.durable_function.execution_id`
- `lambda.durable_function.execution_name`

## Background
- In previous PRs
(DataDog/datadog-lambda-python#728,
DataDog/datadog-lambda-js#730), tracer adds
attributes `aws_lambda.durable_function.execution_id` and
`aws_lambda.durable_function.execution_name` to the `aws.lambda` span

## Details

### Data flow
1. `TraceAgent::handle_traces()` detects an `aws.lambda` span carrying
`request_id`, `durable_function_execution_id`, and
`durable_function_execution_name` in its meta tags
2. It sends a `ProcessorCommand::ForwardDurableContext { request_id,
execution_id, execution_name }` to `InvocationProcessorService`
3. `Processor::forward_durable_context()` in the lifecycle processor
relays this as a `DurableContextUpdate` to the logs pipeline via an mpsc
channel, using `send().await` to guarantee delivery
4. `LogsAgent::spin()` receives the update and calls
`LogsProcessor::process_durable_context_update()`, which inserts the
entry into `LambdaProcessor::durable_context_map` and drains any held
logs for that `request_id`

### Log holding and draining
- After cold start, the logs processor holds all incoming logs without
flushing them, because it does not yet know whether this is a durable
function
- Held logs are stored in `held_logs: HashMap<String, Vec<IntakeLog>>`,
keyed by `request_id`
- Logs without a `request_id` (e.g. in managed instance mode) are pushed
directly to `ready_logs` and never held, since they cannot carry durable
context
- `durable_context_map: HashMap<String, DurableExecutionContext>` maps
`request_id` to `(execution_id, execution_name)`. It has a fixed
capacity (500 entries) with FIFO eviction
- When the logs processor receives a `PlatformInitStart` event, it
learns whether the function is a durable function:
- If **not** a durable function: drain all held logs (mark them ready
for aggregation and flush)
- If **durable**: drain held logs whose `request_id` is already in
`durable_context_map` (tag them with
`lambda.durable_function.execution_id` and
`lambda.durable_function.execution_name`); keep the rest held until
their context arrives
- When an entry is inserted into `durable_context_map`, any held logs
for that `request_id` are drained immediately

### Memory safety and resilience
- `held_logs` is capped at **50 keys** (intentionally small — see
below). Insertion order is tracked in `held_logs_order:
VecDeque<String>` for FIFO eviction
- When `held_logs` is at capacity and a new `request_id` arrives, the
**oldest key is evicted**: its logs are serialized and pushed to
`ready_logs` without durable context tags. This ensures logs are always
eventually sent to Datadog even if the tracer is not installed and
context never arrives
- The cap is kept small (50) to limit the size of the batch flushed at
shutdown, reducing the risk of the final flush timing out when held logs
are drained without durable context
- At **shutdown**, after draining the telemetry channel:
1. The `durable_context_rx` channel is drained to apply any pending
context updates, maximising the chance logs are decorated before
flushing
2. All remaining `held_logs` are drained to `ready_logs` without durable
context tags, so no logs are lost

### Types
- `DurableContextUpdate { request_id, execution_id, execution_name }` —
message sent from trace agent through lifecycle processor to logs
pipeline
- `DurableExecutionContext { execution_id, execution_name }` — value
type stored in `durable_context_map`

## Test plan

### Manual test

#### Steps
Build a layer, install it on a function, and invoke it.

#### Result
1. In Datadog, all the logs for this durable execution have the two new
attributes
<img width="734" height="421" alt="image"
src="https://github.com/user-attachments/assets/173e3be2-8bb1-4e08-be97-521c63679bf1"
/>


2. The logs query
> source:lambda
@lambda.arn:"arn:aws:lambda:us-east-2:425362996713:function:yiming-durable-py-custom-tracer"
@lambda.durable_function.execution_name:c949fb3d-a8f5-4ae6-a802-b1458149a4b2

returns all the logs for two invocations of this durable execution. It
returns 98 logs, equal to 49 logs for the first invocation + 49 logs for
the second invocation. ([query
link](https://ddserverless.datadoghq.com/logs?query=source%3Alambda%20%40lambda.arn%3A%22arn%3Aaws%3Alambda%3Aus-east-2%3A425362996713%3Afunction%3Ayiming-durable%22%20%40lambda.durable_execution_name%3A2f492839-75df-4acb-9f2a-30b1b36d5c8f&agg_m=count&agg_m_source=base&agg_t=count&cols=host%2Cservice&fromUser=true&messageDisplay=inline&refresh_mode=paused&storage=flex_tier&stream_sort=time%2Cdesc&viz=stream&from_ts=1772655235033&to_ts=1772655838416&live=false))

### Unit tests
Passed the added unit tests

---------

Co-authored-by: Claude Sonnet 4.6 <[email protected]>

## Overview

Right now the `/info` endpoint of bottlecap returns `client_drop_p0s:
true`, among other things. This is wrong, as "true" means the agent
supports client-side P0 span dropping, but we never want the client to
drop spans. In both cases (Agent-Side Stats and Backend Stats), we need
the client to send all spans to the agent. Therefore, this PR changes
the value from `true` to `false`.

## Testing 
N/A. Let me know if there's a good way to test this.

## Notes
Thanks @ajgajg1134 @lucaspimentel @purple4reina for proposing this
change and contributing to some words in the PR summary.

Add Ruby to the list of supported runtimes for tracing since we support
that

…ion to START/END/REPORT logs (#1158)

## Summary

- Extracts the `aws_lambda.durable_function.first_invocation` tag from
the `aws.lambda` span (sent by the tracer) and adds it as an attribute
on `START`, `END`, and `REPORT` platform logs for durable functions.
This tag will be used by UI to identify durable execution start time and
apply time filter properly.
- The tag flows through the existing `DurableContextUpdate` pipeline:
`trace_agent` → `processor_service` → lifecycle processor → logs agent
- `START`/`END`/`REPORT` logs are already held until durable context
arrives (from #1053); `first_invocation` arrives in the same update, so
no additional holding logic is needed
- Non-platform (function) logs are unaffected
- Renames serialized durable log attributes to the `durable_function.*`
namespace for consistency with tag spans

## Test plan

### Automated testing
The touched unit tests passed.

### Manual testing
`START` and `END` logs for the first invocation have `first_invocation:
true`.
<img width="532" height="338" alt="image"
src="https://github.com/user-attachments/assets/1df450c6-d54f-4e81-89ee-fbedc5e4a48e"
/>

`START` and `END` logs for subsequent invocations have
`first_invocation: false`.
<img width="522" height="289" alt="image"
src="https://github.com/user-attachments/assets/2488d3cd-d05e-4824-9ab8-707c3249f907"
/>

Other logs are not affected
<img width="518" height="397" alt="image"
src="https://github.com/user-attachments/assets/e64d231e-26de-4f2b-a8f0-799ca7fc1dcd"
/>

---------

Co-authored-by: Claude Sonnet 4.6 <[email protected]>

## Summary

Add support for AWS delegated authentication, allowing Lambda functions
to authenticate with Datadog using their IAM role instead of static API
keys. This mirrors the implementation in the main Datadog agent ([PR
#46272](DataDog/datadog-agent#46272)).

**How it works:**
1. Lambda function's IAM role signs an STS `GetCallerIdentity` request
2. The signed request is sent to Datadog's `/api/v2/intake-key` endpoint
as authentication proof
3. If the role is configured in Datadog's intake mapping, a managed API
key is returned
4. Falls back to other API key methods (Secrets Manager, KMS, SSM,
static) if delegated auth fails

**Note**: This function is in preview, customers will currently need to
request access to use it.

## Tests
- [x] Added an integration test that uses this new auth flow, verifies
that we have logs in our Datadog Serverless account for this new lambda.
Note that the IAM role needs to be added to a Datadog account mapping so
the IAM role we are using for this integ test is hardcoded to be the
same regardless of who is running it.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 4.5 <[email protected]>

…stop warning flood (#1161)

## Summary

- **Root cause:** After `on_platform_report` removes a context from `context_buffer`, the corresponding `ReparentingInfo` entry was left in `sorted_reparenting_info` indefinitely (capacity 500). Every subsequent trace batch caused `update_reparenting` to iterate all stale entries and emit a `WARN` for each one, producing a flood of `"Mismatched request info. Context not found for request_id"` messages in CloudWatch.
- **Fix:** Call `sorted_reparenting_info.retain(...)` immediately after `context_buffer.remove(request_id)` in `on_platform_report` to prune the completed invocation's entry.
- **Tests:** Two regression tests added — one verifying the entry is pruned after `on_platform_report`, one reproducing the exact production sequence (invoke → add_reparenting → report → trace batch) to confirm stale entries no longer appear in `get_reparenting_info()`.

Fixes https://datadoghq.atlassian.net/browse/SLES-2810

## Test plan

- [x] `cargo test test_reparenting_info_pruned_after_on_platform_report` passes
- [x] `cargo test test_update_reparenting_ignores_completed_invocations` passes
- [x] Full lifecycle test suite: 218 passed, 0 failed

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: tianning.li <[email protected]>

…te (#1174)

## What changed and why

Added `--import-existing-resources` flag to the `npx cdk deploy` command
in the `integration-suite` CI job
(`.gitlab/templates/pipeline.yaml.tpl`).

**Root cause**: When a pipeline fails mid-deploy, some AWS resources
(specifically the dotnet Lambda log group
`/aws/lambda/integ-{IDENTIFIER}-{TEST_SUITE}-dotnet-lambda`) are created
in AWS but the CloudFormation stack is left in `ROLLBACK_COMPLETE`
state. On a pipeline retry for the same commit (same `IDENTIFIER` =
`CI_COMMIT_SHORT_SHA`), CDK attempts to create the already-existing log
group and fails with:

```
ToolkitError: ChangeSet 'cdk-deploy-change-set' on stack 'integ-{IDENTIFIER}-{TEST_SUITE}' failed early validation:
  - Resource of type 'AWS::Logs::LogGroup' with identifier '/aws/lambda/integ-{IDENTIFIER}-{TEST_SUITE}-dotnet-lambda' already exists.
```

The `--import-existing-resources` flag tells CDK to import any
already-existing resources into the stack instead of failing validation,
which is the standard CDK solution for this exact scenario.


## Jira

[SVLS-8825](https://datadoghq.atlassian.net/browse/SVLS-8825)

[SVLS-8825]:
https://datadoghq.atlassian.net/browse/SVLS-8825?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

## What does this PR do?

SnapStart restore invocations were being misclassified as
`proactive_initialization=true, cold_start=false`. The root cause is in
`set_init_tags()`: it uses `sandbox_init_time` (captured at snapshot
creation) to measure how long ago the sandbox was initialized. For
SnapStart, this gap is always large (snapshot creation vs. restore), so
the >10s threshold is always exceeded.

**Fix**: Add a `restore_time` field to `Processor`, set from the
existing `PlatformRestoreStart` telemetry event. For SnapStart
functions, `set_init_tags()` now measures time since the restore — not
since snapshot creation.

## Changes

- `bottlecap/src/config/aws.rs` — Added `is_snapstart()` method (mirrors
`is_managed_instance_mode()` pattern)
- `bottlecap/src/lifecycle/invocation/processor.rs` — Added
`restore_time: Option<Instant>`, set in `on_platform_restore_start()`,
used in `set_init_tags()` for SnapStart-aware cold start detection
- `integration-tests/tests/snapstart.test.ts` — Added `cold_start=true`
assertion for restore invocations and `cold_start=false` for warm
invocations (Java + .NET, 2 threads × 2 invocations each with 5s delay)

## Scope

- **Java + .NET only** — Python SnapStart requires a tracer-level fix
(separate ticket: SVLS-5988)
- **Node.js** — AWS does not support SnapStart for Node.js

## Tests

Integration test suite: `integration-tests/tests/snapstart.test.ts`

Assertions added:
- Restore invocations: `cold_start=true`, `init_type=snap-start`,
`snapstart_restore` span present, no `cold_start` span
- Warm invocations: `cold_start=false`, `init_type=snap-start`, no
`snapstart_restore` span
- Trace isolation: all 4 invocations have unique trace IDs

## Jira

[SVLS-8230](https://datadoghq.atlassian.net/browse/SVLS-8230)

…n tests (#1177)

## Summary
- Increases bottlecap compile job timeout from 10m to 20m. This seems to
be frequently timing out.
- Adds `retry: 2` to `integration-suite` to handle transient failures
from AWS/Datadog API throttling

---------

Co-authored-by: Claude Sonnet 4.6 (1M context) <[email protected]>

…1176)

## Summary

- Reverts #1118 (`feat(traces): [SVLS-8734] respect
Datadog-Client-Computed-Stats header`) which introduced logic to skip
backend stats when the tracer claims client-computed-stats, causing
stats to vanish entirely in some scenarios.
- Reverts #1136 (`fix(tests): remove stale _dd.compute_stats:1 assertion
from logs integration test`) which was a follow-up test adjustment for
#1118.

Restores the pre-v95 behavior where `_dd.compute_stats` is set solely by
`DD_COMPUTE_TRACE_STATS_ON_EXTENSION`, keeping the backend as a safety
net.

## Test plan

- [x] `cargo fmt --check` passes
- [x] `cargo clippy --all-targets -- -D warnings` passes
- [x] `cargo test` — all 513 tests pass

[SVLS-8734]:
https://datadoghq.atlassian.net/browse/SVLS-8734?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

## Overview

Reintroduces `_dd.base_service` for AWS Lambda environments to support service remapping rules and correct trace stats migration during integration override removal.

### Changes

**`span_inferrer.rs`** — Adds `_inferred_span.tag_source: "self"` and `_inferred_span.synchronicity` to all synthetic spans (including wrapped SNS/SQS/EventBridge spans). This tag is used as the identifier to conditionally set `_dd.base_service` downstream.

**`trace_processor.rs`** — Replaces the previous behavior of unconditionally removing `_dd.base_service` from all spans. Instead:
- Sets `_dd.base_service` only on inferred spans (identified by `_inferred_span.tag_source`)
- Does not overwrite `_dd.base_service` if already set by the tracer (preserving Python/JS layer behavior)
- Resolves the value as: `DD_SERVICE` → function name → `"aws.lambda"` (respects `DD_TRACE_AWS_SERVICE_REPRESENTATION_ENABLED`)
- Covers extension-only languages: Go, Java, .NET, Ruby

## Testing

Unit tests added in `trace_processor.rs` covering:
- Uses function name when `DD_SERVICE` is not set
- Uses `DD_SERVICE` when configured
- Falls back to `"aws.lambda"` when `DD_TRACE_AWS_SERVICE_REPRESENTATION_ENABLED` is disabled
- Does not set `_dd.base_service` on non-inferred spans
- Does not overwrite `_dd.base_service` already set by the tracer

Co-authored-by: zarir.hamza <[email protected]>

…ger secrets (#1146)

## Summary

- When `DD_API_KEY_SECRET_ARN` is set and the fetched secret is a JSON
object, automatically extract the `dd_api_key` field as the API key
- Falls back to the raw secret string if the value is not valid JSON or
the `dd_api_key` field is absent — preserving existing behavior for
plain-string secrets
- No new environment variable introduced; the JSON key name is hardcoded
as `dd_api_key`

## Test Plan
- [x] Unit tests cover JSON extraction (`dd_api_key` present), fallback
to raw (key absent), and plain string secrets
- [x] Verify with a real Secrets Manager secret in JSON format:
`{"dd_api_key": "<your-key>"}`
- [x] Verify plain-string secrets continue to work unchanged
- [x] Integration test using [test
function](https://us-east-1.console.aws.amazon.com/lambda/home?region=us-east-1#/functions/integ-tianning-base-node-lambda?subtab=envVars&tab=testing),
secret in
[Json](https://us-east-1.console.aws.amazon.com/secretsmanager/secret?name=secret-in-json&region=us-east-1)
and secret in [plain
text](https://us-east-1.console.aws.amazon.com/secretsmanager/secret?name=securet-with-plain-text&region=us-east-1).
The positive and negative tests all performed as expected.

Co-authored-by: Claude Sonnet 4.6 <[email protected]>

…ts (#1178)

## What changed and why

Updated `integration-tests/package-lock.json` to resolve 12 Dependabot
security alerts:

- **#127** fast-xml-parser: Entity Expansion Limits Bypassed (Moderate)
- **#126** handlebars: Property Access Validation Bypass (Low, Dev)
- **#125** handlebars: Prototype Method Access Control Gap (Moderate,
Dev)
- **#124** handlebars: JavaScript Injection in CLI Precompiler (High,
Dev)
- **#123** handlebars: JavaScript Injection via AST Type Confusion
(High, Dev)
- **#121** handlebars: JavaScript Injection via @partial-block (High,
Dev)
- **#120** handlebars: JavaScript Injection via AST Type Confusion
(Critical, Dev)
- **#118** brace-expansion: Zero-step sequence causes process hang
(Moderate)
- **#117** handlebars: Prototype Pollution Leading to XSS (Moderate,
Dev)
- **#114** picomatch: Method Injection in POSIX Character Classes
(Moderate, Dev)
- **#113** yaml: Stack Overflow via deeply nested collections (Moderate)
- **#112** fast-xml-parser: numeric entity expansion bypass (High)

All affected packages are transitive dependencies. `npm audit fix`
updated 19 packages and `npm audit` now reports **0 vulnerabilities**.

## Test approach

No source code changes were made — only `package-lock.json` was updated.
Integration tests are not required for lockfile-only changes.

## Verification

```
npm audit
# found 0 vulnerabilities
```

Co-authored-by: Claude Sonnet 4.6 (1M context) <[email protected]>

…1124)

## Overview
For two logs related to span dedup, change the log level from WARN to
DEBUG so they won't appear in customer log by default, since default log
level is WARN. No action is needed on customer side.

They sometimes indicate that traces/spans are dropped, but there's no
easy way to fix it.

## Testing 
N/A

---------

Co-authored-by: Claude Sonnet 4.6 <[email protected]>
Co-authored-by: jordan gonzález <[email protected]>

## Summary
- Bumps `EXTENSION_VERSION` constant from `95-next` to `96-next`

## Test plan
- [ ] Verify extension reports correct version tag in Lambda traces