[codex-analytics] centralize thread analytics state

[rhan-oai]

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

---

Stack created with Sapling. Best reviewed with ReviewStack.

• [codex-analytics] emit terminal tool review events #18748
• [codex-analytics] add tool review event schema #18747
• [codex-analytics] emit tool item events from item lifecycle #17090
• [codex-analytics] add tool item event schemas #17089
• [codex-analytics] replay protocol-native item timing #20239
• [codex-analytics] expose item timing through app server #20515
• [codex-analytics] add core item timing production #20514
• -> [codex-analytics] centralize thread analytics state #20300

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ffbe9fe5c4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve thread connection when recording subagent start

Avoid unconditionally overwriting thread_state.connection_id here. If SubAgentThreadStarted is ingested after emit_thread_initialized for the same thread (a common ordering), this replaces the real thread connection with the parent (or None). Later context resolution for guardian/compaction uses this field, so events can be misattributed to the wrong client/runtime or dropped entirely.

Useful? React with 👍 / 👎.

[rhan-oai]

@codex

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Can't wait for the next one!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[owenlin0]

i find that there are a lot of concepts to understand, can we simplify?

seems like the branch added a fairly abstract mini-framework:

• AnalyticsDropSite: where the event was dropped
• MissingAnalyticsContext: why it was dropped
• AnalyticsConnectionSource: how to find the connection
• ThreadMetadataRequirement: whether metadata is needed
• ResolvedAnalyticsContext: the resolved output

are all those necessary?

wonder if we can have a resolve_analytics_context that looks something like:

let Some((connection_state, thread_metadata)) =
    self.thread_context_or_warn("compaction", &input.thread_id, Some(&input.turn_id))
else {
    return;
};

or something like that