restatedev
Support additional context + content type for Errors
It is sometimes useful to attach additional information to a TerminalError, in addition to a textual description. especially for errors that are intended to terminate an ingress connection. Let’s consider an additional context field to a terminal error that contains an opaque binary+content type. Then the ingress can use that field instead of a generic text/plain description message. This would be optional, and allow folks to return richer, structured error messages.
A solution as proposed here https://github.com/restatedev/restate/issues/2842#issue-2898211535 with extensions is indeed an interesting one. This extensions can just be map<string, string> and then people can put in there json values, or whatever else they would like.
@slinkydeveloper would be great if that was a json node, instead of a string map. As json that are serialized into string, suffer from escaping, and require a pre-processing phase.
would be great if that was a json node, instead of a string map. As json that are serialized into string, suffer from escaping, and require a pre-processing phase.
I need to think this through how it would work from an API perspective, It might be a problem to expose this in all the SDKs where we try to not take hard dependencies on json (think java). Also map<string, string> might be enough for majority of use cases 🤷
Why not just map<string, unknown>? Or even just any valid JSON value. The user can then cast/validate it manually according to their schema.
Why not just map<string, unknown>
I'm afraid this is not so easy, because in some statically typed languages unknown is not possible, we need to have some concrete type, think Rust for example. We would need to at least restrict to JSON values, but this also means we would need in all SDKs to take hard dependencies on Json data structure dependencies, plus there's the question of how to transport this on protobuf (there's the json protobuf support, but this in some languages needs an additional dependency).
I think map<string, string> is generally a good starting point, and perhaps we evolve it in future if we need to support json values.
Not really familiar with protobuf, but I suppose that makes sense. map<string, string> seems good enough for the use-cases I'm thinking of at least.