For monitoring purposes and to facilitate higher-level retry logic, it would be helpful to include the entire payload of the buffer sent when emitting send and error events.
Currently the send and error events inform the user only of the statement component of first and last lines in the buffer that was sent (or attempted to send). Unfortunately since the logger is managing buffering, it's generally not possible to know all of the lines between the first and last, so there's no way to know all of the lines that were involved in the event. In addition, the data passed to the log() call in the meta option is not included. With this change, the send and error events will include a new buffer member that is simply the raw buffer that was sent. This will of course include both the statement and the meta (in stringified form), as well as other fields. The event handlers can handle deserializing the metadata as needed, so the logger need not bother.
Many users may not need this information included, and excluding it would allow it to be garbage collected sooner, so it would be best to make the inclusion of this data in the event optional based on a configuration option such as verboseEvents.
For monitoring purposes and to facilitate higher-level retry logic, it would be helpful to include the entire payload of the buffer sent when emitting
send
anderror
events.Currently the
send
anderror
events inform the user only of thestatement
component of first and last lines in the buffer that was sent (or attempted to send). Unfortunately since the logger is managing buffering, it's generally not possible to know all of the lines between the first and last, so there's no way to know all of the lines that were involved in the event. In addition, the data passed to thelog()
call in themeta
option is not included. With this change, thesend
anderror
events will include a newbuffer
member that is simply the raw buffer that was sent. This will of course include both thestatement
and themeta
(in stringified form), as well as other fields. The event handlers can handle deserializing the metadata as needed, so the logger need not bother.Many users may not need this information included, and excluding it would allow it to be garbage collected sooner, so it would be best to make the inclusion of this data in the event optional based on a configuration option such as
verboseEvents
.