Skip to content

[codex-analytics] add core item timing production#20514

Draft
rhan-oai wants to merge 1 commit intomainfrom
rhan/core-item-timing-production
Draft

[codex-analytics] add core item timing production#20514
rhan-oai wants to merge 1 commit intomainfrom
rhan/core-item-timing-production

Conversation

@rhan-oai
Copy link
Copy Markdown
Collaborator

@rhan-oai rhan-oai commented Apr 30, 2026

Why

Protocol-native item timing needs a producer-side foundation before any public wire or replay consumer can depend on it. This stage keeps that groundwork together so the timing model can be reviewed without app-server schema churn or TUI replay changes mixed in.

Repeating started_at_ms on end events lets reducers consume a complete interval from the completion event itself instead of retaining request-time state, which keeps the timing data colocated in one place.

What changed

  • Adds native lifecycle timing fields to the core protocol model for tool families that already emit begin/end events.
  • Captures and propagates timestamps across core producers for web search, image generation, MCP, dynamic tools, command execution, patch application, and collaboration tools.
  • Adds focused core integration coverage for protocol-native item timing, including web search, image generation, MCP completion, and interrupted user-shell commands.

Verification

  • cargo test -p codex-core web_search_item_is_emitted
  • cargo test -p codex-protocol

Stack created with Sapling. Best reviewed with ReviewStack.

@rhan-oai rhan-oai requested a review from a team as a code owner April 30, 2026 22:28
@rhan-oai rhan-oai force-pushed the rhan/core-item-timing-production branch from 5c272b8 to c6e0ea5 Compare April 30, 2026 22:57
@rhan-oai rhan-oai marked this pull request as draft April 30, 2026 22:59
@rhan-oai rhan-oai force-pushed the rhan/core-item-timing-production branch 2 times, most recently from 7a61984 to 88c1fb0 Compare April 30, 2026 23:32
rhan-oai added a commit that referenced this pull request May 1, 2026
## Why

Several analytics event families need the same per-thread attribution
state: the app-server client/runtime associated with a thread and, for
lifecycle-oriented events, the thread metadata captured during
initialization. Keeping connection ids and lifecycle metadata in
separate maps made each consumer rebuild the same thread context and
made subagent attribution harder to resolve consistently.

## What changed

- Replaces the separate thread connection and metadata maps with one
reducer-owned `threads` map.
- Routes guardian, compaction, turn-steer, and turn analytics through
shared thread-state lookups while preserving turn-origin attribution for
turn events and request-origin attribution for steer events.
- Lets newly observed spawned subagent threads inherit their parent
thread connection so later thread-scoped analytics can resolve through
the same state model.
- Adds regression coverage for standalone `SubAgentThreadStarted`
publication plus the `SubAgentSource::ThreadSpawn` parent fallback
through a thread-scoped consumer that depends on inherited connection
state.

## Verification

- `cargo test -p codex-analytics`

---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/20300).
* #18748
* #18747
* #17090
* #17089
* #20239
* #20515
* #20514
* __->__ #20300
Base automatically changed from rhan/thread-analytics-state to main May 1, 2026 01:58
@rhan-oai rhan-oai force-pushed the rhan/core-item-timing-production branch 2 times, most recently from d55b667 to 42cdca0 Compare May 1, 2026 02:53
@rhan-oai rhan-oai force-pushed the rhan/core-item-timing-production branch from 42cdca0 to d7b376e Compare May 1, 2026 16:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant