Hi Rusty,
Thanks for taking a look!
I like the idea of being able to reference a specific message/field
that your node finds problematic. Definitely makes the job simpler
than trying to define every error evar.
> erroneous_message is the message we're complaining about (including
2-byte type),
Carla Kirk-Cohen writes:
> Hi all,
Hi Carla,
I apologize for not responding to this earlier, but it was
raised again in the recent spec meeting
(https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-07-05-20.06.log.html).
I love the idea of more specific error
Hi all,
I’d like to make a case for re-purposing the existing error message
(17) in the spec to allow for more structured errors, and create a
path for standardized, enriched errors going forward.
As is: the error message contains an arbitrary string, and is used to
communicate fatal errors
