lightninglabs
[feature]: structured error codes for price oracles
The error code in an OracleError potentially returned by a price oracle is, at present, an unstructured uint8. We simply want to start adding some structure here, defining useful codes that price oracles can use to report errors (e.g. asset not supported) and that we can handle gracefully in turn.
This subsumes e.g. #1326 and possibly #1501.
Note that these error codes are described briefly in bLIP29, so any practical change here may need a corresponding update there, or vice versa.
In https://github.com/lightninglabs/taproot-assets/issues/1326#issuecomment-3201203282 I mention I think #1326 is different because it is tapd's response, not the price oracle's response that I'm asking to change. I also think https://github.com/lightninglabs/taproot-assets/issues/1501 is different because again, it is tapd's behavior I want changed not the price oracle server's.
You're right -- there's nothing stopping tapd from receiving an error code of 0, but relaying a custom message. I'll reopen that one and we can pick it up there.
I'm actually going to close this because I now (only a few hours later) think it to be misguided. Absent any pressing need, we probably shouldn't mess with error codes that are spec'd in the bLIP, and, as @ZZiigguurraatt points out, we can productively just relay any errors returned from a price oracle.
I'm reopening this, because I again think it to be.. uh, appropriately guided.
The crux is that a useful distinction can be made between the codes for RFQ rejection errors, which are defined at the protocol level, and oracle errors. Whilst an edge node may not want to divulge exactly why a given RFQ was rejected, it may want to communicate benign information to a peer, e.g., again, "asset not supported."
Adding some structure to the oracle error codes would allow an edge node to distinguish the former case from the latter and respond appropriately. In the event where an edge node wants to keep the oracle error to itself, it can reject the RFQ with error code 0 and some generic message; if it wants to communicate a reason for the rejection, it can respond with the same code of 0, but add a custom message describing what happened.
We may eventually want to update the bLIP to define additional error codes for RFQ rejection messages, but adding some structure to oracle errors can be done independently of that.