go-chi / go-chi/chi

Custom middleware recovery having to be duplicated

Open
#911 2 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.