logr
logr copied to clipboard
go-logr
If logging as JSON and the type is json.RawMessage log it "as-is"
If we're already producing JSON and a sub message field is json.RawMessage (i.e. []byte) then emit it as-is.
Otherwise you get [X,Y,Z,..] style which is pretty useless in the log in that form.
I'm not sure about this. How would code know that it is okay to pass a json.RawMessage as a value? This is only useful in code which will only ever be used with funcr configured to emit JSON output, which kind of defeats the purpose of go-logr as a general-purpose logging API.
That's why this is in the funcr specific code that is logging in JSON format. It's scoped directly to that and not in the general case on purpose.
The reason for it is if you have a json.RawMessage you likely want to see it in string form not [X,Y,Z] form. Converting it to string by casting to string also doesn't work as the pretty printer gets involved at that point and escapes all the JSON.
The other option would be to add a struct tag which adds an option when logging which says "just stringify this as-is".
i.e.
type Message struct {
Data json.RawMessage json:"data" funcr:"stringify"
}
So instead of [X,Y,Z] you'd just get the json string in there directly.
Thoughts?
That's why this is in the funcr specific code that is logging in JSON format. It's scoped directly to that and not in the general case on purpose.
Let me rephrase: how will this feature be used in log calls? How does that code know that passing such a special value is okay? Or is this code never meant to be used with any logger other than funcr with JSON output?
That's why this is in the funcr specific code that is logging in JSON format. It's scoped directly to that and not in the general case on purpose.
Let me rephrase: how will this feature be used in log calls? How does that code know that passing such a special value is okay? Or is this code never meant to be used with any logger other than funcr with JSON output?
Yes, that's the idea. This is specific to funcr and its ability to easily render as JSON instead of KV pairs.
My working example of this was a gRPC server that was taking a proto.Message and serializing as JSON before passing to OPA for policy evaluation. The OPA system sees the []byte and can treat that as a direct string but we can't log the request in human readable format today without this. i.e. [X,Y,Z] form or I cast the RawMessage to a string but then the pretty printer turns it into escaped JSON which isn't useful either.
Hmm...one issue I just ran into is if the type is json.RawMessage but the length is 0. I suppose in that case we should force a {} into it as an empty arg.
