Description
When using createError, I would like the ability to provide information that is logged internally (e.g. for auditing, support, or debugging purposes) but is NOT passed on to the user or frontend. This would allow recording extra context or diagnostic data securely, without risking exposure of sensitive details to clients.
My use case is that there is information I need to capture on the backend when an error occurs, but passing a logger or additional context to every error location is not always feasible or ergonomic. Ideally, createError could have a dedicated property or field intended for internal use only, with a clear guarantee that this data is never serialized or sent to the client.
Proposed Solution
It would help to have a new property on the object passed to createError (e.g. 'internal', or similar) whose contents are only logged/stored on the backend, and are never exposed in any user-facing response. The library would ensure this property is ignored in all serialization or output to users.
If you have a preference for how this could be implemented (naming, integration etc.), please share it.
I would also be happy to help with the implementation!
Description
When using createError, I would like the ability to provide information that is logged internally (e.g. for auditing, support, or debugging purposes) but is NOT passed on to the user or frontend. This would allow recording extra context or diagnostic data securely, without risking exposure of sensitive details to clients.
My use case is that there is information I need to capture on the backend when an error occurs, but passing a logger or additional context to every error location is not always feasible or ergonomic. Ideally, createError could have a dedicated property or field intended for internal use only, with a clear guarantee that this data is never serialized or sent to the client.
Proposed Solution
It would help to have a new property on the object passed to createError (e.g. 'internal', or similar) whose contents are only logged/stored on the backend, and are never exposed in any user-facing response. The library would ensure this property is ignored in all serialization or output to users.
If you have a preference for how this could be implemented (naming, integration etc.), please share it.
I would also be happy to help with the implementation!