feat(sources): complete cgfy's remaining unread Claude Code wire keys - #3465
Conversation
Problem: polylogue-cgfy's corpus enumeration found requestId (1,171 sampled occurrences) and thinkingMetadata.maxThinkingTokens (34 occurrences) among the wire keys never read anywhere in polylogue/sources/. requestId is the Anthropic API's per-call correlation id (distinct from Claude Code's own record uuid or a tool call's own id) -- real cross-reference value against provider-side billing/support records. thinkingMetadata.maxThinkingTokens is the extended-thinking token budget configured for the turn, a reasoning- effort signal distinct from the actual token counts already captured. Solution: both are top-level fields on the raw record (not inside `message`), so `_message_usage_event_payload` gains a `record` parameter and the sole call site (the existing `message_usage` session-event append) now passes `item`. Reachable immediately through the existing generic `message_usage` session-event surface with no new consumer code needed: `Session.session_events` -> CLI `read --view events` -> `run_session_events` (polylogue/cli/messages.py) and MCP `get(ref, projection="events")` (polylogue/mcp/server_cutover.py:905) already render every session_events row regardless of event_type. Verification: devtools test tests/unit/sources/test_claude_code_unread_wire_fields.py tests/unit/sources/test_parsers_claude_code_artifacts.py -> 13 + 38 passed. Anti-vacuity: each new field has a paired "absent" test asserting the key is omitted, not fabricated as None/empty.
Problem: polylogue-cgfy AC1 requires every key in its corpus enumeration classified read / deliberately-dropped-with-reason / to-acquire, recorded in the Claude Code OriginSpec fidelity declaration. The structuredPatch/ file_edits cluster and the message.stop_reason/cache_creation/todos cluster were already classified in a prior fidelity_notes entry; the bead's "other unread keys of substance" list (slug aside, already covered) had no disposition recorded anywhere. Solution: added a fidelity_notes entry to the Claude Code OriginSpec covering requestId/thinkingMetadata (READ, this branch's prior commit), userType (MEASURED NEGATIVE -- reconfirmed constant "external" against a second live corpus), sourceToolAssistantUUID (DROPPED, verified equal to the already-captured parentUuid), hookCount/hookInfos (DROPPED, a less complete duplicate of source.db's raw_hook_events), and toolUseID (already consumed via the documented claude_delegation_progress disposition, not a bare unread field). Verification: devtools test tests/unit/sources/test_origin_specs.py -> 15 passed.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
Next review available in: 51 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe Claude Code parser now captures non-empty ChangesClaude Code usage metadata
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@polylogue/sources/parsers/claude/code_parser.py`:
- Around line 754-758: Update the maxThinkingTokens validation in the
thinking_metadata handling to accept only non-negative integers, while
continuing to exclude booleans; omit payload["max_thinking_tokens"] for negative
values. Add a -1 fixture and assert that the field is omitted.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: e8df8a4d-4cbc-4367-8202-7564c52fe51c
📒 Files selected for processing (3)
polylogue/sources/origin_specs.pypolylogue/sources/parsers/claude/code_parser.pytests/unit/sources/test_claude_code_unread_wire_fields.py
CodeRabbit review on PR #3465: a negative thinkingMetadata.maxThinkingTokens is not a real token budget and should be omitted rather than persisted. Adds the >= 0 guard plus a -1 fixture asserting omission. Verification: devtools test tests/unit/sources/test_claude_code_unread_wire_fields.py -> 14 passed.
1 participant
Summary
Closes out the remainder of polylogue-cgfy's disposition work now that PR #3442 landed the flagship consumption gap (structuredPatch/originalFile/oldString -> file_edits, reachable via API + MCP + CLI
read --view file-edits). Adds the two remaining genuinely-unread, real-value wire keys (requestId,thinkingMetadata.maxThinkingTokens) and records the full disposition (read / measured-negative / deliberately-dropped-duplicate) for the rest of the bead's "other unread keys of substance" list in the Claude Code OriginSpec'sfidelity_notes, satisfying AC1.Problem
polylogue-cgfy's 2026-07-29 corpus enumeration found 34 of the 70 most common Claude Code wire keys with zero references in
polylogue/sources/. The structuredPatch/originalFile/oldString cluster (105K/92K/86K rows) and most of the "other keys of substance" list (stop_reason,stop_sequence,cache_creation,ttftMs,todos,toolUseResult.sandbox/filenames/numFiles,slug) were captured by prior sessions on this bead and PR #3442, but two items remained genuinely unread with no recorded disposition either way:requestId(1,171 sampled occurrences -- the Anthropic API's per-call request id) andthinkingMetadata.maxThinkingTokens(34 occurrences -- the extended-thinking token budget). The bead's remaining lower-value items (userType,sourceToolAssistantUUID,hookCount/hookInfos,toolUseID) also had no recorded disposition, so AC1 ("every key... classified... recorded in the Claude Code OriginSpec fidelity declaration") was incomplete.Verified each of those lower-value items directly against a real ~/.claude/projects corpus before classifying:
userTypeis the literal string"external"on every sampled record (measured negative, same class as the bead's ownusage.service_tierfinding).sourceToolAssistantUUIDequals that same record's ownparentUuid, already captured asParsedMessage.parent_message_provider_id-- a duplicate spelling, not new evidence.hookCount/hookInfosdescribe hook firings already tracked durably (with outcome, whichhookInfoslacks) insource.db'sraw_hook_events.toolUseIDis already consumed for its real signal (theprogress/agent_progressdelegation-edge disposition documented incode_parser.py's module docstring).Also discovered en route:
masterHEAD (5798b3d) failed to import at all (ImportError: cannot import name 'literal_check') -- #3458 deleted it as a supposed zero-call-site dead shim, but #3451 had wired real call sites into it earlier the same day. Fixed and merged separately as #3464 so this branch could even run tests; this branch is rebased on top of that fix.Solution
polylogue/sources/parsers/claude/code_parser.py:_message_usage_event_payloadgains arecordparameter (the top-level recorditem, sincerequestId/thinkingMetadatalive there, not insidemessage); the sole call site now passesrecord=item. Both new keys ride the existingmessage_usagesession-event payload asrequest_id/max_thinking_tokens.Session.session_events-> CLIread --view events(polylogue/cli/read_views/events.py->run_session_events,polylogue/cli/messages.py) and MCPget(ref, projection="events")(polylogue/mcp/server_cutover.py:905) already render everysession_eventsrow generically regardless ofevent_type-- no new consumer code needed, verified by reading both call chains before writing this PR (the genericeventsprojection was wired by prior work, not this PR).polylogue/sources/origin_specs.py: newfidelity_notesentry on the Claude CodeOriginSpecrecording the full disposition table above.Verification
devtools test tests/unit/sources/test_claude_code_unread_wire_fields.py tests/unit/sources/test_parsers_claude_code_artifacts.py tests/unit/sources/test_origin_specs.py-> 57 passeddevtools verify --quick-> exit 0 (format, lint, mypy, render all --check, schema-versioning policy)Ref polylogue-cgfy
Summary by CodeRabbit
Enhancements
Quality Improvements