[SERVER-83553] Support unique_ptr and shared_ptr in logv2 Created: 23/Nov/23  Updated: 28/Nov/23

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Ivan Fefer Assignee: Backlog - Service Architecture
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Service Arch
Participants:

 Description   

Sometimes for debug or logging purposes we need to output a container of smart pointers.

It would be convenient to support this in our logv2 library



 Comments   
Comment by Billy Donahue [ 28/Nov/23 ]

I have a few concerns about introducing these inside logv2 directly.

My preference would be to introduce a loggable proxy type that can be logged. This proxy type would be customizable to the needs of the caller. This way we don't have to try to find a one-size-fits-all generic solution and embed it into logv2.

We don't log raw pointers, so I I'm concerned about the expectation that they would be loggable if some smart pointers are loggable.

Lots pointer-like types are missing from the discussion, notablly T*.

When logging a pointer, is the intent that the pointer value appear in the log or that the pointee should be serialized into the log? If the pointee cannot be serialized, logging the pointer will be invalid, and perhaps should not be. We try not to "leak" exact pointer values in the log at all in production, as a security measure.

A pointer can be a polymorphic, unlike an optional. So there are some issues here about how to stringify through a polymorphic interface. I don't really want to try for a generic solution for that problem, as it's perhaps best handled by the caller of LOGV2.

Analogy to boost::optional breaks down a bit, because we have historically used boost/optional_io.hpp and optionals were loggable with operator<<, but we don't do that anymore, and use util/optional_util.h instead, for API compatibility with std::optional. So supporting them the way we are is bit of a concession to that legacy.

Generated at Thu Feb 08 06:52:31 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.