Remove overly verbose data from custom formatter

[cravend]

This PR modifies the LogFormatter to filter overly verbose items out of the custom object logged with each entry. Currently, the following items are filtered:

const ignoredCustomData = [
  'time',
  'pid',
  'hostname',
  'msg',
  'res',
  'req',
  'reqId',
  'responseTime',
]

These items are used elsewhere in the log formatter, and including them in the custom object is redundant.

It also adds tests to ensure that these keys are removed.

After:

api | 10:35:43 🌲 incoming request GET xxx /auth?method=getToken
api | 10:35:43 🌲 Starting a postgresql pool with 1 connections.
api | 🗒 Custom
api | {
api |   "prisma": {
api |     "clientVersion": "4.14.0"
api |   },
api |   "target": "quaint::pooled",
api | }
api | 10:35:43 🌲 request completed 66ms
api | 10:35:43 🌲 incoming request POST xxx /graphql
api | 10:35:43 🐛 Parsing request to extract GraphQL parameters
api | 10:35:43 🐛 Processing GraphQL Parameters
api | 10:35:43 🐛 graphql-server GraphQL execution started: __REDWOOD__AUTH_GET_CURRENT_USER
api | 10:35:43 🌲 request completed 21ms
api | 10:35:43 🐛 graphql-server GraphQL execution completed: __REDWOOD__AUTH_GET_CURRENT_USER
api | 10:35:43 🐛 Processing GraphQL Parameters done.

Before:

api | 10:35:43 🌲 incoming request GET xxx /auth?method=getToken
api | 🗒 Custom
api | {
api |   "time": 1684074943416,
api |   "pid": 30701,
api |   "hostname": "Daltons-Air",
api |   "reqId": "req-1",
api |   "req": {
api |     "method": "GET",
api |     "url": "/auth?method=getToken",
api |     "hostname": "localhost:8910",
api |     "remoteAddress": "::1",
api |     "remotePort": 54521
api |   },
api |   "msg": "incoming request"
api | }
api | 10:35:43 🌲 Starting a postgresql pool with 1 connections.
api | 🗒 Custom
api | {
api |   "time": 1684074943437,
api |   "pid": 30701,
api |   "hostname": "Daltons-Air",
api |   "prisma": {
api |     "clientVersion": "4.14.0"
api |   },
api |   "timestamp": "2023-05-14T14:35:43.437Z",
api |   "target": "quaint::pooled",
api |   "msg": "Starting a postgresql pool with 1 connections."
api | }
api | 10:35:43 🌲 request completed 66ms
api | 🗒 Custom
api | {
api |   "time": 1684074943482,
api |   "pid": 30701,
api |   "hostname": "Daltons-Air",
api |   "reqId": "req-1",
api |   "res": {
api |     "statusCode": 200
api |   },
api |   "msg": "request completed"
api | }
api | 10:35:43 🌲 incoming request POST xxx /graphql
api | 🗒 Custom
api | {
api |   "time": 1684074943545,
api |   "pid": 30701,
api |   "hostname": "Daltons-Air",
api |   "reqId": "req-2",
api |   "req": {
api |     "method": "POST",
api |     "url": "/graphql",
api |     "hostname": "localhost:8910",
api |     "remoteAddress": "::1",
api |     "remotePort": 54524
api |   },
api |   "msg": "incoming request"
api | }
api | 10:35:43 🐛 Parsing request to extract GraphQL parameters
api | 🗒 Custom
api | {
api |   "time": 1684074943549,
api |   "pid": 30701,
api |   "hostname": "Daltons-Air",
api |   "msg": "Parsing request to extract GraphQL parameters"
api | }
api | 10:35:43 🐛 Processing GraphQL Parameters
api | 🗒 Custom
api | {
api |   "time": 1684074943549,
api |   "pid": 30701,
api |   "hostname": "Daltons-Air",
api |   "msg": "Processing GraphQL Parameters"
api | }
api | 10:35:43 🐛 graphql-server GraphQL execution started: __REDWOOD__AUTH_GET_CURRENT_USER
api | 🗒 Custom
api | {
api |   "time": 1684074943564,
api |   "pid": 30701,
api |   "hostname": "Daltons-Air",
api |   "msg": "GraphQL execution started: __REDWOOD__AUTH_GET_CURRENT_USER"
api | }
api | 10:35:43 🌲 request completed 21ms
api | 🗒 Custom
api | {
api |   "time": 1684074943567,
api |   "pid": 30701,
api |   "hostname": "Daltons-Air",
api |   "reqId": "req-2",
api |   "res": {
api |     "statusCode": 200
api |   },
api |   "msg": "request completed"
api | }
api | 10:35:43 🐛 graphql-server GraphQL execution completed: __REDWOOD__AUTH_GET_CURRENT_USER
api | 🗒 Custom
api | {
api |   "time": 1684074943565,
api |   "pid": 30701,
api |   "hostname": "Daltons-Air",
api |   "msg": "GraphQL execution completed: __REDWOOD__AUTH_GET_CURRENT_USER"
api | }
api | 10:35:43 🐛 Processing GraphQL Parameters done.
api | 🗒 Custom
api | {
api |   "time": 1684074943565,
api |   "pid": 30701,
api |   "hostname": "Daltons-Air",
api |   "msg": "Processing GraphQL Parameters done."
api | }

---

Closes #8318

[replay-io]

18 replays were recorded for 18ad691.

0 Failed

18 Passed

• useAuth hook, auth redirects checks

  locator.waitFor: Target closed
  =========================== logs ===========================
  waiting for locator('text=Username `testuser@bazinga.com` already in use') to be visible
  ============================================================

• Check that a specific blog post is prerendered
• Check that about is prerendered
• Check that homepage is prerendered
• Check that meta-tags are rendering the correct dynamic data
• Check that rehydration works for page not wrapped in Set
• Check that rehydration works for page with Cell in Set
• Check that rehydration works for page with code split chunks
• Check that you can navigate from home page to specific blog post
• Waterfall prerendering (nested cells)
• RBAC: Admin user should be able to delete contacts
• RBAC: Should not be able to delete contact as non-admin user

  page.waitForNavigation: Navigation failed because page was closed!
  =========================== logs ===========================
  waiting for navigation to "**/" until "load"
  ============================================================

• Smoke test with dev server
• Smoke test with rw serve
• Loads Cell mocks when Cell is nested in another story
• Loads Cell Stories
• Loads MDX Stories
• Mocks current user, and updates UI while dev server is running

View test run on Replay ↗︎

[dac09]

Thanks for this also @cravend - would you mind updating the description with a couple of screenshots / small description on what this achieves? (hard to tell from the code)

It also helpful for users to see exactly what got merged without diving into the code :)

[cravend]

Thanks for this also @cravend - would you mind updating the description with a couple of screenshots / small description on what this achieves? (hard to tell from the code)

It also helpful for users to see exactly what got merged without diving into the code :)

Done @dac09 :-)

[dthyresson]

Thanks @cravend I'll review soon. I had initially thought of a different implementation rather than ignoring those attributes -- but I have to remember what it was (and it may not have worked). Let me try to recall what that was so I can review better.

Thanks so much for taking this on!

[dthyresson]

Thanks @cravend ! Approved!

Sorry this got off my review list for so long. This definitely makes logs cleaner and easier to read.

I might decide to add in the req url and /or id on the main message line at some point if we find that having the request url in a more serverful log is helpful.

Thanks again and I'll merge when CI completes.

Thanks again!

[cravend]

Thanks @cravend ! Approved!

Sorry this got off my review list for so long. This definitely makes logs cleaner and easier to read.

I might decide to add in the req url and /or id on the main message line at some point if we find that having the request url in a more serverful log is helpful.

Thanks again and I'll merge when CI completes.

Thanks again!

Sounds good! Thanks :-)

Just so you know, the req url is in the main message already (but ID and hostname are not).

[dthyresson]

Thanks @cravend ! Approved!
Sorry this got off my review list for so long. This definitely makes logs cleaner and easier to read.
I might decide to add in the req url and /or id on the main message line at some point if we find that having the request url in a more serverful log is helpful.
Thanks again and I'll merge when CI completes.
Thanks again!

Sounds good! Thanks :-)

Just so you know, the req url is in the main message already (but ID and hostname are not).

Oh you’re right. Perfect! Thanks again!

[jtoar]

Talked with @thedavidprice, we're not sure if this is breaking or not strictly but since we're taking away information that people could be relying in some edge case in production, we just don't feel comfortable releasing it in a minor. v6 is on the horizon, or at least not too far away, so we'll get this out then. Thanks @cravend!