Repository navigation
Add lightweight Core request logs - #690
Merged
Merged
Conversation
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.
Core now exposes a lightweight Request log in Web so operators can see incoming API requests, HTTP results, elapsed time and safe error codes. Public and administration traffic have independent bounded windows, preventing console polling from evicting application requests. Filters and local request details reuse the administration API; no database, telemetry backend or setting is added.
The existing response writer records metadata without buffering bodies or changing streaming, implicit Content-Type, HEAD or error behavior. Entries distinguish active, completed and aborted HTTP requests; these states do not claim an asynchronous Agent Turn has completed. Raw paths, query values, headers, payloads, credentials and error messages are not collected. Each window holds the latest 1,000 started requests for the serving API instance and resets at restart; completion metadata also uses the existing process logger.
Validation: full API unit tests, targeted race and real-HTTP writer tests, Core build/vet, OpenAPI freshness, Web/client typechecks, 744 client and 392 Web unit tests, three request-log browser workflows and bilingual visual checks, website build and 22 documentation/website checks. Fresh independent review found no actionable issues.
Microbenchmark with the production JSON/context logger writing to discard: about 14–15 µs added per request, with allocations increasing from 3,360 to 4,642 bytes; reading the bounded 1,000-entry window takes about 196–208 µs. Real log sink latency is not included. Machine transports and full distributed tracing are outside this change.
Need help on this PR? Tag
@codesmith-botwith what you need.