Add reverse RPC and hook callback timing traces

[aurokin]

Summary

Add opt-in, measurement-only timing for inbound reverse JSON-RPC requests and SessionHooks callbacks under the github_copilot_sdk::reverse_rpc_timing tracing target.

The trace separates request forwarding and scheduling, hook callback execution, response encoding, writer queue delay, write_all, flush, and final completion. Each phase includes a request-relative start offset so consumers can reconstruct the timeline.

Safety and behavior

• Keeps request processing, callback, serialization, writer queue, flushing, timeout, and error behavior unchanged.
• Creates no timing queues, registry, counter, keyed hasher, or timing task unless DEBUG is enabled for the target before client construction.
• Uses bounded, nonblocking timing queues. Saturation reports records_dropped rather than delaying RPC work.
• Carries the exact inbound request generation through routing, including reused numeric request IDs.
• Uses per-client keyed, generation-specific correlation values.
• Emits only fixed RPC method and hook type labels. It does not trace prompts, hook payloads or results, tool arguments, commands, paths, environment values, raw JSON, session IDs, or secrets.

Validation

• cargo +nightly-2026-04-14 fmt --check
• cargo clippy --all-features --all-targets -- -D warnings
• cargo test --all-features --lib with 256 tests passing
• RUSTFLAGS='-D warnings' cargo check --all-features
• github-app combined E2E backend build against the earlier integration commit completed successfully
• Final independent branch review found no significant issues

Integration

Consumers must install a tracing subscriber with github_copilot_sdk::reverse_rpc_timing=debug before constructing the SDK client. Enabling the directive later does not add timing infrastructure to an existing client.

[Copilot]

Copilot review overview

Review tier: Balanced
Findings: 1 · 1 · 1

New issues introduced by this change (3)

Severity	Finding
	rust/​src/​jsonrpc.rs — Timing remains active for every outbound JSON-RPC frame even when reverse-RPC tracing was disabled…
	rust/​src/​session.rs — This drain runs before the receiver is closed, while its router sender remains registered until the…
	rust/​src/​jsonrpc.rs — The timing consumer still runs on a Tokio worker, and each debug! call invokes the subscriber…

What changed in this PR

Adds opt-in reverse JSON-RPC and hook callback timing traces to the Rust SDK.

Changes:

• Correlates inbound requests through routing, dispatch, and response writing.
• Emits bounded timing records for request, hook, encoding, queue, write, flush, and completion phases.
• Adds extensive timing, saturation, cancellation, and redaction tests.

File	Description
rust/​src/​jsonrpc.rs	Implements timing infrastructure, correlation, emission, and tests.
rust/​src/​session.rs	Propagates traces through session request dispatch.
rust/​src/​router.rs	Routes trace-carrying reverse requests.
rust/​src/​lib.rs	Enables timing-aware client construction and responses.
rust/​src/​hooks.rs	Measures hook callback execution.
rust/​src/​github_token.rs	Preserves traces through token dispatch.
rust/​src/​copilot_request_handler.rs	Preserves traces through inference dispatch.
rust/​Cargo.toml	Adds timing-test dependencies and features.
rust/​Cargo.lock	Locks added tracing dependencies.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[SteveSandersonMS]

Thanks for the detailed safety/redaction writeup — that part of the thinking is solid, and we absolutely want to support legitimate diagnostic needs for the GitHub App team. But before we can review the design itself, we need context that isn't in the PR body, commits, or timeline (which currently has zero comments or linked issues):

1. What specific problem prompted this — an incident, a customer-reported latency issue, a perf investigation? Do you have data showing reverse-RPC/hook latency is actually a problem today?
2. Is this meant to be permanent production instrumentation, or a temporary tool to diagnose one issue (in which case it probably shouldn't land on main in this shape)?
3. The runtime process brokers reverse RPC to all 6 SDK languages already — why instrument only the Rust SDK client rather than the shared runtime, which would give the same visibility once instead of per-language?
4. You mention a "github-app combined E2E backend build" — is the github-app team the actual consumer here? Has this been discussed with anyone else on the SDK side, or scoped against the other 5 languages?

Once we understand the actual need, we can talk concretely about whether the current ~2,500-line design (and its currently-failing tests, e.g. closed_forward_channel_records_failed_forward_before_abandonment) is the right shape for it.

[SteveSandersonMS]

Marked as draft for tracking purposes - please set to "ready to review" when applicable.