Per-request JSON-RPC log capture via the haskell-logging entry list#4151
Merged
Conversation
… flag and haskell-log-entries response field Adds the new wire fields to all five JSON-RPC request/result types (execute, simplify, implies, get-model, add-module) with no behavioural change. `haskell-logging :: Maybe Bool` on requests and `haskell-log-entries :: Maybe [Value]` on results lay the groundwork for the per-request log-bundle capture described in the downstream spec; current results all set `Nothing` for the new field. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…Capture: add per-request log-capture infrastructure
Introduces a shared `Collector` (TVar-backed unbounded buffer of
serialized log entries) and two engine-specific capture LogActions:
* Kore.Log.LogCapture: filters SomeEntry by registered TypeRep
(DebugAttemptEquation, DebugApplyEquation, DebugTerm) and writes
entries as JSON Values via the new entryToJsonValue helper extracted
from renderJson.
* Booster.Log.LogCapture: filters LogMessage by CLContext presence
(CtxProxy, CtxDetail, CtxAbort, CtxSimplify), plus a teeLogger
combinator for fan-out.
No wiring yet — these modules are stand-alone primitives the proxy
will compose against per-request.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Member
Author
|
Note that because this is adding logging contexts in various places in the RPC server, it may be better to review with |
…ire per-request capture into both engine loggers
Adds two engine-side wiring components for the LogCapture
infrastructure:
* `withBoosterCapture` runs a `LoggerMIO` action with the
booster-side capture tee'd onto the existing logger, no-op when
no collector is supplied.
* `KoreCaptureRegistry` is a `TVar (Map ThreadId Collector)` owned
by `KoreServer`; the static kore log action consults it via the
new `registryLogAction`, fanning matching entries to the
collector registered for the calling thread. `withKoreCapture`
brackets a request's IO action with the per-thread
registration.
`Server.hs` constructs one registry at startup, appends
`registryLogAction registry` to `koreLogActions`, and threads the
registry through `mkKoreServer` into the new `KoreServer.captureRegistry`
field. No request handler consults the registry yet — that wiring
comes in the per-endpoint plumbing commits.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…kell-logging capture
Threads the new flag through the proxy's main dispatch. Before
case-dispatching, respondEither now wraps the inner action with a
single helper that:
1. Creates a per-request Collector when the request opts in.
2. Installs the booster-side tee via withBoosterCapture.
3. Registers the collector against the calling thread in the
shared KoreCaptureRegistry so kore log entries land in the
same buffer.
4. Drains the buffer and writes haskellLogEntries onto whichever
result variant was produced.
ProxyConfig gains the (shared) KoreCaptureRegistry; Server.hs
wires it. Result reconstruction uses RecordWildCards so the
@DuplicateRecordFields@-shared field name resolves unambiguously
through the API GADT.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…r-integration-tests: add round-trip test for haskell-logging capture Adds an RPC integration test for the per-request `haskell-logging` flag: sends an `execute` request with `haskell-logging: true` and asserts the response carries a non-empty `haskell-log-entries` array, plus a control request without the flag asserting the field is omitted. Reuses the small `a-to-f` definition via a symlink. The capture happens in the proxy, so the test runs only under kore-rpc-booster. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ster/tools/{Proxy,Server}, test-haskell-log-capture: carry per-request haskell-logging entry list
Replaces the fixed-bundle `haskellLogging :: Maybe Bool` flag with
`haskellLogging :: Maybe [Text]` on all five endpoints: the request now names
exactly which log entries to capture, so the default set lives downstream (pyk)
and can evolve without a backend release. `Nothing`/`Just []` capture nothing;
`Just names` captures exactly the named entries.
The flat name list spans both engines and is passed to each; each matches only
the names it recognises and ignores the rest, so a name unknown to both is
silently skipped (making pyk/backend version skew safe):
- kore: names are resolved to entry types via the log registry
(`koreTypesFromNames`), skipping unknowns instead of erroring at module load;
the per-request type set is registered per thread. The capture action is also
composed outside `koreLogFilters`, so capture no longer depends on the
server's `-l`/`--log-entries` configuration.
- booster: names match against a message's context stack by `clContextName`
(new, in `ContextLog`) — the `Ctx`-stripped CamelCase constructor name, which
is a tag-only match for the `UniqueId`-carrying contexts (`"Rewrite"` matches
any `CtxRewrite _`).
The integration test now sends a name list and asserts subset selection.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ehildenb
changed the title
CI enforces HLint as well as Fourmolu; note that both must pass on every commit, not just the final one. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
jberthold
approved these changes
Jun 4, 2026
Collaborator
jberthold
left a comment
jberthold
left a comment
There was a problem hiding this comment.
The idiom of "injecting" the captured logs after the fact is a bit confusing at first (assigning haskellLogentries = Nothing everywhere) but a good way to add this with few code changes.
I would still refactor it to use the existing LogLine type and existing rendering code paths where possible.
| , valid :: Bool | ||
| , condition :: Maybe Condition | ||
| , logs :: Maybe [LogEntry] | ||
| , haskellLogEntries :: Maybe [Value] |
Collaborator
There was a problem hiding this comment.
I think it would be good to use the LogEntry type here, just like the context log.
haskell-backend/kore-rpc-types/src/Kore/JsonRpc/Types/ContextLog.hs
Lines 193 to 198 in e92393a
Collaborator
There was a problem hiding this comment.
Using the LogLine type would start in this file, replacing all Value instances by LogLine (and importing it).
Other files would follow the type changes, and there will be some code shared with the existing context logging.
…ster/tools/Proxy: capture entries as structured LogLine, not Value
Addresses review feedback: store captured entries as the structured `LogLine`
type (from `ContextLog`, the same type the context log uses) instead of opaque
`Value`. The `Collector` now buffers `LogLine`s and the `haskell-log-entries`
response field is `Maybe [LogLine]`.
- booster: builds a `LogLine` directly — its context stack is already
`[CLContext]`, and the message is wrapped as `CLText`/`CLValue`.
- kore: reuses `entryToJsonValue` (so a captured entry stays identical to its
on-disk JSON-log form) and parses it back into `LogLine`; kore's context
vocabulary is the same `CLContext` the context log models. A parse failure
falls back to a context-less line carrying the raw value, keeping capture
total.
The emitted JSON is unchanged (`LogLine`'s ToJSON is the `{timestamp?, context,
message}` shape), so the wire format is identical.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Member
Author
|
Done — switched the Collector, the haskell-log-entries field, and both capture paths to the structured LogLine type. Booster builds it directly from its [CLContext] stack; kore reuses entryToJsonValue and parses into LogLine (its context vocabulary is the same CLContext), with a total fallback. The emitted JSON is unchanged since LogLine's ToJSON is the same {context, message} shape. (bc0e7fe) |
`teeLogger` and `boosterCaptureLogger` are only used internally by `withBoosterCapture`; drop them from the export list to keep the module's API surface minimal. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.
Adds an opt-in
haskell-loggingfield to every JSON-RPC request: the request names which log entries to capture, and the matching entries from both engines are returned in-band on the response'shaskell-log-entriesfield. This lets a client (pyk/KEVM) collect structured backend logs per request — with exact per-request attribution — without parsing a shared stderr/file stream or correlating across concurrent server processes. The set of entries to capture lives in the request (and thus downstream), so it can evolve without a backend release; the backend stays a generic "capture these entry types for this request, return them in-band" mechanism with no hardcoded policy. Capture is purely additive — the existing stderr/file logger is unaffected — and is independent of the server's-l/--log-fileconfiguration.Nothing/[]capture nothing.Changes:
haskell-logging :: Maybe [Text](the entry/context names to capture) on requests,haskell-log-entries :: Maybe [Value]on results. Defaults to absent, so existing clients are unaffected.Collector(Kore.JsonRpc.Types.LogCapture) that both engines write into; the proxy drains it intohaskell-log-entriesat response time.clContextName, with tag-only matching for id-carrying contexts such asCtxRewrite), so a name unknown to both is silently skipped — keeping client/backend version skew safe.koreLogFilters, so it does not depend on the server's-l/--log-entriesconfiguration; unrecognised names are skipped at runtime rather than failing the request.BoosterAdaptor.entryToJsonValueis factored out ofrenderJsonso captured entries are byte-for-byte equivalent (modulo whitespace) to the--log-format jsonfile output.hlinton every commit.Validation:
cabal build all, fourmolu, and hlint pass at every commit.test-haskell-log-capture) sends a name list and asserts subset selection; runs underkore-rpc-boosterin CI.a-to-fdefinitions: a kore-only name list returns only kore-engine entries, a booster-only list returns only booster entries, narrowing to["Proxy"]returns only proxy-context entries, an unknown name is skipped without error, and an empty/absent field captures nothing.