Claude/kg retrieval logs merge m4tvyg - #143
Merged
Merged
Conversation
take_callback_logs drops entries below the requested log level, but the
level it was given comes from the merge task -- and that traces back to
`response.get("log_level")` on the callback body in the /callback route. A
TRAPI response has no log_level field for a retrieval service to echo, so
that read is None on every callback and the level defaults to INFO no matter
what the client asked for.
The lookup workers do forward log_level on the way out, so a DEBUG query
gets DEBUG entries back from the retrieval -- and then had them stripped
against an INFO that was never asked for.
Resolve the level from the stored query instead, which the merge child
already loads, so no extra fetch: DEBUG entries survive a DEBUG query, and a
retrieval that reports at DEBUG regardless still can't flood one that asked
for INFO. The child's own logger follows the same level.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012QwdpTHjvsiTS1wfuq395b
The /callback handler read the requested level off the body a subservice posted. A TRAPI response has no log_level field, so that read was None on every callback: the handler, the merge task it enqueues, and everything downstream of that ran at INFO no matter what the client asked for. Read it from the stored query instead -- the only record of what was asked for once a request is handed off. get_query_log_level does that lookup, and the callback handler resolves the query before it logs anything, so its own records are at the right level too, not just the ones it hands on. The level is now understood in one place: resolve_log_level over a single name->number mapping, used by query intake, the callback handler, the merge child (which reads the level off the query it already loads), and the filter for log entries a retrieval sends back. Intake previously indexed logging._nameToLevel directly, so a query naming a level we don't know -- "VERBOSE", say -- failed with a KeyError instead of falling back. Costs one small Redis read of the query blob per callback, on a path that already does two postgres lookups and a write. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012QwdpTHjvsiTS1wfuq395b
Codecov Report❌ Patch coverage is
... and 2 files with indirect coverage changes Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
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
2 participants
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.
No description provided.