[#179]: Add v0.144.0 regression guards for paste-corrupted session entries#186
Merged
Conversation
…ion entries Codex v0.144.0 (PR #31494) fixed a TUI-level bug where pasting terminal control sequences corrupted resumed conversation history in JSONL session files. Sessions captured before the fix may contain two corruption forms: - Raw ESC bytes in a line (invalid JSON) — already silently skipped by serde_json::from_str(...).ok()? in RawEntry::parse() - Unicode-escaped control sequences (�[1m) in string values (valid JSON, garbled content) — already parsed without panicking Add four tests that explicitly document and lock in this behavior: - entry.rs: invalid JSON line is silently skipped - entry.rs: response_item with \u001b-encoded sequences parses correctly - entry.rs: all four standard v0.144.0 entry types round-trip correctly - turn.rs: turn building completes without panic when history contains garbled response_item content No functional code changes — the parser already handles both cases.
…L corruption Codex v0.144.0 (PR #31494) fixed paste-triggered corruption of conversation history where terminal control sequences (ESC = U+001B) could be embedded unescaped inside JSON strings, producing syntactically invalid JSON lines in session JSONL files. The parser already handled this gracefully: - entry.rs: RawEntry::parse uses serde_json::from_str(...).ok()? which returns None for any invalid JSON line - session.rs: parse_session_inner uses filter_map(RawEntry::parse) which silently skips None results - discover.rs: scan_session_file uses Err(_) => continue to skip unparseable lines during the discovery scan Add regression tests to document and lock in this behavior: - entry.rs: verify corrupted line returns None; adjacent valid line still parses correctly - session.rs: verify a full session with a corrupted line produces the correct turns from surrounding valid entries - discover.rs: verify discover_sessions still returns the correct turn_count when a JSONL file contains a corrupted line Fixes #179
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #179
Summary
Codex v0.144.0 (upstream PR #31494) fixed a TUI-level bug where pasting terminal control sequences into the Codex prompt window corrupted resumed conversation history written to JSONL session files. This PR adds regression tests confirming that
codex-trace's parser already handles both corruption forms gracefully.Root cause (upstream)
When a user pasted text containing ANSI escape sequences into the Codex TUI before v0.144.0, the sequences were written into the JSONL session file in one of two forms:
�inside a string value. The line is technically valid JSON but the content is garbled display text.Parser behaviour (already correct)
RawEntry::parse()inentry.rsis the entry point for every JSONL line:serde_json::from_strreturnsErr,.ok()?short-circuits toNone, andfilter_mapinsession.rssilently drops the line. No panic.payloadfield; downstream code never inspects the raw string bytes. No panic.No functional code change is needed — the parser already handles both cases.
Changes
Added four tests that document and lock in the existing behaviour:
entry.rsv0144_paste_corrupted_invalid_json_line_is_silently_skippedparse()returnsNoneentry.rsv0144_response_item_with_unicode_escaped_control_sequences_does_not_panic�-encoded sequences → parses correctly, no panicentry.rsv0144_all_standard_entry_types_parse_correctlyturn.rsv0144_paste_corrupted_resumed_history_response_item_does_not_crash_turn_buildingCompleteVerification