Continue incoming traceparent past the ADOT layer wrapper [Bug-1150]

Story 1150Epic None7 files · +300/−4

PR #291 · pramaan-io/pramaan-functions · merged 2026-06-10

Why this matters

The trace ID dies at the layer wrapper.

Story nine-eighty-eight

Traceparent silently dropped — new root, broken flow.

The fix — Incoming traceparent dies at the layer wrapper; shadowing it with a repo-root shim keeps the trace alive.

How it flows

sequenceDiagram
  autonumber
  participant A as Caller
  participant B as Repo-root shim
  participant C as ADOT layer wrapper
  participant D as Lambda handler
  A->>B: event + traceparent
  B->>B: shadow layer (Python resolves /var/task first)
  B->>D: Context with traceparent
  B-->>C: layer wrapper bypassed

src/shared/observability/lambda_wrapper.py

Methodin → outwhat it does
HandlerError(class)signals a clean failure when the handler module can't be loaded
modify_module_name(module_name) → strrewrites the handler module path so import resolves to the right place
custom_event_context_extractor(lambda_event) → Contextpulls traceparent out of the Lambda event and injects it into the Context — the real hero
load_lambda_handler() → Anyloads the actual handler function that the wrapper will invoke

What changed, file by file

Vendors the PR #727 context extractor from the upstream ADOT layer; ships a custom event context extractor and handler loader so the repo-root shim can continue an incoming traceparent past the layer's wrapper. Temporary — delete once the pinned layer ships the fix.

new classsignature
HandlerError(class)
modify_module_name(module_name) → str
custom_event_context_extractor(lambda_event) → Context
load_lambda_handler() → Any

Files changed (7)

File±
.github/workflows/deploy-admin-api.yml ★+5 −1
.github/workflows/deploy-app-api.yml+5 −1
.github/workflows/deploy-ingest-api.yml+5 −1
.github/workflows/provision-agents-infra.yml+1 −1
otel_wrapper.py ★+13
src/shared/observability/lambda_wrapper.py ★+112
tests/unit/shared/observability/test_lambda_wrapper.py+159