softwaremill / tapir

Rapid development of self-documenting APIs

Home Page:https://tapir.softwaremill.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Enhancing ServerLog handling of decode failures

kciesielski opened this issue · comments

Inspired by a discussion on the Community Forum: https://softwaremill.community/t/how-to-customize-logging-with-the-server-log-interceptor/361

We need better customization and safety in the default logging of decode failures in ServerLog.

Current Challenges:

  1. Limited/inconvenient control of the logging level
    Users can't easily change the logging level for decode failures (e.g., from debug to warn) if a request is considered "handled and returning a 4xx response". Such errors go to doLogWhenHandled, which is not always intuitive, especially since there's an additional doLogAllDecodeFailures method and .logAllDecodeFailures(Boolean) flag that doesn't control such cases.
  2. Customisation of error message
    The default message is preformatted as (link)
s"Request: ${showRequest(ctx.request)}, handled by: ${showEndpoint(
            ctx.endpoint
          )}${took(token)}; decode failure: ${ctx.failure}, on input: ${ctx.failingInput.show}; response: ${showResponse(response)}"

To change this, the user has to write their extension of DefaultServerLog and override decodeFailureHandled.

  1. Safety of ${crx.failure}
    If the failure is of type DecodeFailure.Error, it has a field called original: String containing the full input body. In case of JSON decoding errors, it's the full JSON body, which in many cases shouldn't be printed due to its length and possibly sensitive information.