feat(sdk): structured JSON logging + per-request ms.Log(ctx)#127
Merged
Conversation
The SDK had zero slog — module authors logged unstructured text to stderr, so the platform Logcat had nothing attributable to read. Add a JSON slog handler on stdout as the process default (captured by CloudWatch in prod and the `mirrorstack dev` runner in dev) plus a per-request middleware that attaches a correlated *slog.Logger to the context — tagged with the trusted module_id/request_id/app_id/user_id/app_role — exposed as ms.Log(ctx). request_id prefers the Lambda AwsRequestID (shares CloudWatch's grouping), else a fresh dev id. Level via MS_LOG_LEVEL (default info). The SDK's own stderr diagnostics are left as-is. First slice of the module log pipeline (dev half); the dispatch ingest + ring, CLI tap, and web swap follow. Co-Authored-By: Claude Opus 4.8 (1M context) <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
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.
What
First slice of the module log pipeline (dev half). The SDK had zero
slog— module authors logged unstructured text to stderr, so the platform Logcat had nothing structured/attributable to read. This adds the source side:sloghandler on stdout as the process default (configureLogging), captured identically by CloudWatch (prod Lambda) and themirrorstack devrunner (dev) — no transport code. Level viaMS_LOG_LEVEL(defaultinfo).requestLogMiddleware, mounted after the dev-schema middleware so identity is established; runs on both serving paths since it only reads context). Tags each line with the trustedmodule_id/request_id/app_id/user_id/app_role.ms.Log(ctx) *slog.Logger— the sanctioned author API.request_idprefers the LambdaAwsRequestID(shares CloudWatch's own request grouping), else a freshids.NewUUID().The SDK's own stderr diagnostic logger is left as-is (low-volume; deferred).
Why it's safe / minimal
Everything reuses primitives already vendored:
ms.AppID/auth.Getfor the trusted identity,internal/ids.NewUUID, andaws-lambda-go/lambdacontext(already a dep). No new dependencies;+177lines, one new file + two small wirings.Verification
go build ./...green;go test ./internal/core/green (incl. the newlogging_test.gopinning the correlation fields end-to-end through the middleware + theAwsRequestID-preferred request id);gofmtclean.Next slices: dispatch Redis ring +
POST /internal/modules/{id}/logsingest → CLI runner tap → webuseModuleLogsswap.🤖 Generated with Claude Code