I believe they can use a LogHandler with the non-default errors serialization.
Thank you all the participants for the discussion. The review process is now concluded — we accept the new addition to the LogHandler API for propagating errors. The only condition I would suggest is we first tackle the LogHandler LogEvent proposal and add Error onto of that one to avoid unnecessary deprecated API in the LogHandler.
Thank you @samuelmurray for writing the proposal and handling all the feedback! Please, change the status of the proposal to "Ready for Implementation" and you're welcome to prepare the implementation PR later ![]()
2 Likes
Sounds good! Thanks everyone for the productive review!
2 Likes
Will do! Yeah, I fully agree that it makes sense to await the LogEvent proposal before implementing this.
3 Likes