Fix llm logs --data-ids using response id for conversation id#1464
Open
alvinttang wants to merge 1 commit into
Open
Fix llm logs --data-ids using response id for conversation id#1464alvinttang wants to merge 1 commit into
alvinttang wants to merge 1 commit into
Conversation
`llm logs --data-ids` was added in simonw#800 so callers could join the JSON output back against the responses table. It populates a `response_id` key with `row["id"]` and a `conversation_id` key, but both assignments read `row["id"]`, so every emitted item carries the response ULID under both keys and the conversation reference is lost. The existing regression test (`test_logs_schema_data_ids`) only asserted that the keys exist, not their values, which is why this slipped in. Patch reads `row["conversation_id"]` for the conversation key. The SQL in `logs_list` already selects `responses.conversation_id`, so no schema or query change is needed. Added `test_logs_schema_data_ids_values` that asserts the two ids differ and that the conversation id matches the fixture value ("abc123"). It fails on main and passes with the fix. Refs simonw#800
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
1 participant
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.
Summary
llm logs --data-idspopulates bothresponse_idandconversation_idin the emitted JSON items with the response ULID. The conversation reference the flag exists to provide — and that #800 explicitly documented as the use case ("a--data-idsoption which includes the response and conversation IDs") — is silently lost, so the join back to the responses table doesn't work.Root cause
llm/cli.pyaround line 1916 (block introduced by commiteafe141):The selecting SQL (
responses.conversation_id, around line 1509) already exposes the right column onrow. The second assignment just reads the wrong field. The existingtest_logs_schema_data_idsonly checked key presence (not values), so this was invisible to CI.Fix
3-LOC change in
llm/cli.py:row["id"]→row["conversation_id"]in the conversation key assignment. No schema or query change needed.Tests
New
test_logs_schema_data_ids_valuesintests/test_llm_logs.py(29 LOC). Asserts:response_id != conversation_idconversation_id == "abc123"(the fixture value)RED proof on main:
GREEN after patch: 755 passed in
tests/(network-required tests skipped).ruff check+black --checkclean.Risk notes
row["conversation_id"]can be NULL if a response was logged without a conversation. JSON will then emitnull— same behaviour as any other null cell in logs output; not a new regression.Refs #800