pino: logs in context decoration breaks mergingObject msg field when only mergingObject is passed in as an argument #2410
Description
Description
When using the Node.js agent decoration without forwarding option for Logs in Context with pino, if the logger API is called with a mergingObject instead of a string as the only argument, the library fails to take into account that the msg field in the object, always taking args[1] to decorate and eventually setting msg as undefined NR LINKING xxxx.
Expected Behavior
Pino logs that are submitted as objects with a field msg or message have the msg/message field decorated with the NR LINKING attributes and set correctly.
Steps to Reproduce
Relevant section of newrelic.cjs:
exports.config = {
//...
application_logging: {
forwarding: {
enabled: false,
},
local_decorating: {
enabled: true,
},
},
}
import Pino from 'pino';
const logger = Pino();
logger.error({msg: "mymsg", error: {attribute: "anattribute"}});
If you console log out arguments in the instrumentation file when only a mergingObject is supplied, you get:
[Arguments] {
[node] '0': {
[node] msg: 'mymsg,
[node] error: {
[node] attribute: 'anattribute'
[node] }
[node] },
[node] '1': undefined, // <-- SEE HERE
[node] '2': 50,
[node] '3': ',"time":1722380481790'
[node] }
The resultant badly-decorated log looks like the following after the metadata is added.
{"level":50,"time":1722379746170,"pid":xxx,"hostname":"xxx","msg":"mymsg","error":{"attribute":"anattribute"},"msg":"undefined NR-LINKING|xxx|xxx|xxx|xxx|xxx|"}
This is opposed to just sending a string logger.warn('a string')), which populates args[1] and generates a working log:
{
[node] '0': {},
[node] '1': 'a string',
[node] '2': 40,
[node] '3': ',"time":1722380481791'
[node] }
{"level":40,"time":1722380481791,"pid":xxx,"hostname":"xxx","msg":"a string NR-LINKING|xxx|xxx|xxx|xxx|xxx|"}
Your Environment
newrelic 11.23.2
pino 9.3.2
Additional Context
This is open with NewRelic support as Case #00215731
As a temporary workaround, we can send the msg portion as a second argument to pino in the form of logger.error({ ...OUROBJECT }, msg), but that is cumbersome :) This behaviour is probably unexpected for a JSON logger that's looking for msg!