Custom middleware recovery having to be duplicated
- Dominant language
- Go
- Stars
- 22.8k
- Forks
- 1.2k
- Avg merge
- 5h 17m
- Merged PRs (30d)
- 10
Description
## Context
Hello 👋
I'm still very new to go and might not be interpreting this correctly, but this is my current use case:
My small service:
- is hosted in GCP
- uses `middleware.Logger` only in debug mode = running locally since GCP already does the request logging automatically
- uses the `middleware.Recoverer` (is last middleware, as per docs)
- uses `slog` to manage all logging
## Use case
While in debug mode, everything works as expected, outputs are sent to stdout/stderr and formatted properly.
But while in release mode, when panicking (which I understand should be rare since errors should be properly handled), the panic is caught by the `middleware.Recoverer` and printed to stderr directly (via `PrintPrettyStack`).
I wanted a way to get this output and put it into `slog`.
## Why
The `PrettyPrintStack` outputs multiple lines to stderr, which causes the logger in GCP to interpret each line as an independent log entry.
## Current solution
One alternative I tried was to just copy the parsing logic + middleware.Recover logic into a custom middleware.
Another way was to create a custom middleware that parses & adds LogEntry to context (an adapted version from `middleware.Logger`).
But I would still need to copy the `PrintPrettyStack` parsing functionality either way.
Is it possible to expose just the right functions or args to make it easier?
Or am I missing something (go or chi related) else entirely to make this work?
Contributor guide
Research direction
Start with middleware.Recoverer and PrintPrettyStack, then review how the recovery output is written to stderr. The change is complete when custom recovery can send the stack output through slog without duplicating the recovery or parsing logic; check the existing middleware behavior since no test file is named.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- gcp, go
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100