fix(bench): forward trace headers in DRACO and search response layers

[jamespsterling]

TL;DR

DRACO and search (BrowseComp/HLE/DSQA/WideSearch) inference requests now carry the caller-supplied trace headers, closing the last gap in benchmark trace propagation (#45).

What changed?

• src/benchmarks/draco/benchmark.ts and src/benchmarks/search/core/benchmark.ts now pass input.traceHeaders into makeResponsesLayer, matching the pattern already used by responses-model.ts:

  ...(input.traceHeaders !== undefined && { traceHeaders: input.traceHeaders }),

• Regression tests in both benchmark test files run the real solver against a stubbed fetch and assert traceparent, x-or-traceparent / x-benchmark-trace reach the request while SDK-managed authorization is preserved. Each test fails without its fix.

Why?

#45 threaded traceHeaders from the runner into BenchmarkRunInput, but these two benchmark families built their own makeResponsesLayer and dropped the field, so their requests never stitched to the worker trace.

How to test

bun test src/benchmarks/draco/benchmark.test.ts src/benchmarks/search/core/benchmark.test.ts

Expected: all pass; reverting either source change fails the corresponding new test.

Reviewer focus

• The spread-forwarding lines in the two benchmark.ts files (behavioral change is only these).

Checklist

• Tests cover changed behavior
• Public API or configuration changes are backward compatible, or the break is documented
• Benchmark changes document dataset provenance and licensing
• No credentials, private results, or restricted dataset contents are included
• Documentation is updated where needed

Link to Devin session: https://openrouter.devinenterprise.com/sessions/8669b85c73fb4378aebc0b5476836b6e
Open in Devin Desktop: https://openrouter.devinenterprise.com/desktop/session/8669b85c73fb4378aebc0b5476836b6e?variant=devin
Requested by: @jamespsterling

[devin-ai-integration]

Original prompt from James

Look at all the bench worker traces for ~1 day and see what common errors we see https://us5.datadoghq.com/apm/traces?query=env%3Aproduction%20service%3Abench-worker&agg_m=count&agg_m_source=base&agg_t=count&cols=core_service%2Ccore_resource_name%2Clog_duration%2Clog_http.method%2Clog_http.status_code&fromUser=false&graphType=flamegraph&historicalData=false&messageDisplay=inline&query_translation_version=v0&shouldShowLegend=true&sort=desc&spanType=all&storage=driveline&traceQuery=&view=spans&start=1787195072717&end=1787195972717&paused=false

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[jamespsterling]

@devin pre-existing, but this PR makes the layer path the source of truth for trace headers, so the other inference path is worth naming. All 10 layer call sites now forward. The agent-CLI path forwards none: buildAgentCliEnv at src/benchmarks/agent-cli/runner.ts:114 sets OPENROUTER_API_KEY, TB_MODEL and ORI_OPENROUTER_SESSION_ID but no traceparent, so sandboxed inference is untraced for terminal_bench always, and for deep_swe / swe_atlas whenever the agent is an ori agent (deep-swe/solver.ts:198 branches on cliHarness). sessionId already crosses that boundary as an env var, so the mechanism exists. Is the exclusion deliberate?

[devin-ai-integration]

Yes, deliberate for this PR. Two reasons the agent-CLI env boundary is excluded:

1. Trust-key exposure: x-benchmark-trace is the shared secret cfw-api uses to gate trace continuation + force-sampling. Env vars in the sandbox are readable by arbitrary agent-executed code (and by anything the agent shells out to), so exporting it there widens the secret's exposure surface in a way the header-per-request paths don't. sessionId crosses that boundary because it's not a secret.
2. Static context vs. per-request headers: a traceparent env var would be captured once at sandbox launch and replayed verbatim on every inference request the CLI makes, so all sandboxed requests would claim the same parent span id with no per-request client spans — trace stitching would be misleading rather than partial.

So sandboxed inference (terminal_bench always; deep_swe/swe_atlas on ori-agent harnesses) stays untraced for now, and the new tests assert non-leakage on purpose. If we want coverage there, the cleaner follow-up is for the ori agent CLI to accept trace context via a dedicated flag/env and mint its own child spans per request rather than replaying a fixed traceparent. Happy to file that as a follow-up issue if you want it.