Open andylokandy opened 4 months ago
Hi @andylokandy, thanks for opening this. We can see the potential value in keeping the frame structure in place when deserializing, even at the loss of type information. Is this something you'd be interested in having a stab at implementing?
Thanks! I'm learning the codebase of error-stack recently, and I noticed that the main and hard part is the fmt module, which is a little bit challenging but I'll try to figure it out.
If you have any questions, I am happy to answer them! I know the fmt
module is quite complex, and the code flow isn't ideal (something I hope to change soonâ„¢).
We have had attempts at more specialized serde serialization in #1558, but I haven't had any meaningful time to revisit them.
Related Problem
Context: https://github.com/datafuselabs/databend/issues/15741#issuecomment-2217103934
Proposed Solution
Goal: Provide a solution to send the error collected by a node to another node, and keep propagate the error in the receiver node, and finally pretty print the error frames as if it's all happen in a single stack frame.
Possible solution: A frame stack is consist of several information: context type, location, the source error. The only thing in these three that prevent deserialization is the opaque context type. We can advance the formatting procedure, the default debug hook for
Report
, to serialize the context/attachements into strings/appendix, while keeping the frame structure and the location. At the final fmt procedure, the formatter should be able to recognise this special struct in frame and flatten the frames when rendering.Alternatives
No response
Additional context
No response