Repository navigation
fix(tracing): capture failed CommandExecution items - #127
CNSeniorious000 wants to merge 1 commit into
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
sangkyoonnam
left a comment
There was a problem hiding this comment.
The new tests do catch the bug. With the parent versions of parse.ts and types.ts, 5 of the PR's new tests fail; with the head versions, they pass.
I ran pnpm --config.manage-package-manager-versions=false exec vitest run plugins/tracing/test/parse.test.ts plugins/tracing/test/trace.test.ts on the head three times: 76 passed each time. Then I reverted only parse.ts and types.ts to the parent version (the tests stay at head) and ran the same command three more times: 5 failed, 71 passed each time, and the same 5 failed every run. Those are the four records CommandExecution cases and the trace.test.ts ERROR-level test. The other 71 tests pass on both versions.
Failed
CommandExecutionitems are ignored by theitem_completedhandler, so the matching tool observation can remain atDEFAULTeven when Codex records a failure.Read
failed/declinedcompletions and fill the existing tool call's error by exact ID. Excludeuser_shell, preserve existing errors, output, and timing, and leave legacy completion handling unchanged. Unmatched IDs do not create tools or propagate errors to a code-mode wrapper; cross-turn completions remain out of scope.Tests
ERRORwithout mislabeling a laterwrite_stdincall.pnpm run lintandpnpm testpass (136 tests).