fix: keep manual-instrumentation traces (honor faas.invocation_id; document AWS_LAMBDA_EXEC_WRAPPER)

[parker-edwards]

Problem

There are instances where individuals using the manual layer (dash0-extension-manual) with hand-rolled OpenTelemetry instrumentation in .NET see every trace dropped:

[DASH0] /v1/traces has no invocation IDs, discarding trace
target: aws_lambda_runtime_api_proxy_rs::otlp::receiver

In one example, a handler span is created from a custom ActivitySource ("<service>.Handler") and explicitly sets faas.invocation_id — yet it's still discarded.

Test case environment details

This was detected in an environment with the following attributes:

• Lambda execution with dotnet8 runtime
• Manual instrumentation layer, version 11 (arn:aws:lambda:eu-central-1:115813213817:layer:dash0-extension-manual:11)
• C# with .NET Minimal API
• Deployment via AWS SAM

Root cause

The extension needs an invocation ID to keep a trace, and it has two ways to get one — both missed here:

1. Scope-gated extraction. process_trace_request only reads faas.invocation_id from spans whose instrumentation scope is on the recognized-Lambda allow-list (is_lambda_instrumentation_scope). A custom ActivitySource scope isn't on the list, so the explicitly-set attribute is ignored.
2. Runtime-proxy fallback (get_current_invocation_id) is only populated when the Runtime API proxy runs, which requires AWS_LAMBDA_EXEC_WRAPPER=/opt/wrapper. The Manual Instrumentation docs never mention that variable, so a customer following them has the proxy inactive.

With both missed, the receiver discards the trace.

What this PR does

1. Docs — make the wrapper requirement explicit (the primary fix).
Adds AWS_LAMBDA_EXEC_WRAPPER=/opt/wrapper as a required step in the Manual Instrumentation section, cross-linking the existing Required config note. This is what unblocks the customer: with the proxy active, the fallback stamps every invocation's traces with the AWS request ID regardless of span scope.

2. Code — honor faas.invocation_id from any scope (defense-in-depth).
process_trace_request now extracts faas.invocation_id for invocation correlation from spans in any instrumentation scope, not just allow-listed ones. The README documents faas.invocation_id as the correlation attribute with no scope caveat, so this change should protect against cases where we silently drop spans that have it set via manual instrumentation.

Why the code change is safe and narrowly scoped

• The handler-span rewrites (rename to handler, set kind Internal, reparent to the synthetic root) stay limited to recognized Lambda scopes. Non-Lambda spans are correlated but otherwise left untouched — their trace shape is preserved.
• IDs are de-duplicated before being pushed.
• Auto-instrumentation child spans (HTTP, AWS SDK) don't normally carry faas.invocation_id, so existing auto-instrumentation flows are unaffected; the only behavior change is that an explicitly-set ID is now honored instead of dropped.

Testing

• cargo fmt --all --check — clean
• cargo test --all-features — 267 passed, 0 failed
• New regression tests: process_trace_request_honors_invocation_id_in_non_lambda_scope_without_rewrite (custom .Handler scope → ID extracted, span not rewritten) and process_trace_request_non_lambda_span_without_invocation_id_adds_no_ids.

🤖 Generated with Claude Code