Skip to content

local trace jq recipes in continuous-improvement.md match zero events (tracing-chrome Threaded style) #6676

Description

@bug-ops

Description

Every jq recipe documented in .claude/rules/continuous-improvement.md under "Local Trace Analysis" (e.g. .traceEvents[] | select(.ph=="X" and .dur > 500000)) matches zero events against real local trace files produced by this project's local telemetry backend. This makes the documented trace-analysis workflow non-functional for every span in the codebase, including the new core.anchor.* spans added by issue #6464.

Root cause: tracing-chrome 0.7.2 defaults to TraceStyle::Threaded (lib.rs:90), and build_chrome_layer (src/tracing_init.rs:329) never calls .trace_style() to override it. TraceStyle::Threaded emits only ph:"B"/"E" events with a ts field (lib.rs:340,345) — it never emits ph:"X" with a dur field, which is what every documented jq recipe filters on. Separately, a real trace file sampled during verification (.local/traces/4e8434ee..._20260720T082655.json) is a top-level JSON array, not the {"traceEvents": [...]} object shape the recipes assume, and was found unterminated in that sample (jq failed to parse it at all).

Reproduction Steps

  1. Run a live session with telemetry.backend = "local" in config.
  2. Locate the resulting trace file under .local/traces/.
  3. Run any jq recipe from .claude/rules/continuous-improvement.md, e.g.:
    jq '[.traceEvents[] | select(.ph=="X" and .dur > 500000)] | sort_by(-.dur) | .[0:10]' .local/traces/<file>.json
  4. Observe: empty result / parse error, regardless of how many spans actually ran during the session.

Expected Behavior

The documented jq recipes should return real span duration data for spans in the trace file.

Actual Behavior

  • Recipes filtering on ph=="X" and .dur match nothing, because local traces are written in TraceStyle::Threaded (paired B/E events with ts, no dur).
  • At least one sampled trace file was a bare top-level array (not {"traceEvents": [...]}) and truncated/unterminated, causing jq to fail outright.

Environment

  • Version: unreleased (main, as of 2026-07-28)
  • Features: telemetry local backend (tracing-chrome 0.7.2)

Logs / Evidence

Found during code review of PR for issues #6465/#6464 (anchor doctest + core.anchor.* tracing spans). The new spans render correctly in Perfetto/chrome://tracing (which natively pairs B/E events) and produce correct durations under the OTLP/Jaeger backend — this issue is scoped to the documented jq-based local-trace workflow only, not to span correctness.

Suggested Fix

Either:

  1. Switch build_chrome_layer to .trace_style(TraceStyle::Async) (or otherwise configure ph:"X" emission) so dur-based jq recipes work as documented, or
  2. Rewrite the jq recipes in continuous-improvement.md to pair ph=="B"/ph=="E" events by id/name and compute duration from ts deltas, and drop the .traceEvents wrapper assumption to match the real on-disk array shape.

Metadata

Metadata

Assignees

Labels

P3Research — medium-high complexitybugSomething isn't working

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions