Editoast error management

[leovalais]

Settling on this topic is necessary in order to go forward with the split in crates.

[woshilapin]

Here is a first round, hope you like it. I'm really worried by the complexity of this macro and if there would be some other solution.

[woshilapin]

I'm not sure it's such a QoL improvement when magic is around:

• what will happen when types do not match and compiler errors start to kick in on variants that only exists in these EnumX types?

I believe that, indeed, all of these enums will be a lot of boilerplate code... but once written, not touch again and not a lot.

Also, I'm more for a incremental improvement. We only "think" it might be cumbersome... Let's not fix now, what might never be broken. Said differently, let's address QoL once we have identified a really problem.

I would drop this section personally.

[Khoyo]

I fully agree. Writing error enums isn't fun, but with thiserror it isn't that cumbersome, and has the nice side effect of being usable without refering to same T2 variant...

[leovalais]

The point was to find a way to use them transparently by just using the implicit from() that goes with the ? operator. But after prototyping a bit I couldn't find a way to make that work with rust stable. anon_enum not implementing From either seems to confirm that. I kept the section with an explanation block on why we won't do it, just in case some Rust wizard comes by and magically find a solution... Cf. 717e31d (#237)

[woshilapin]

It's unclear what the use for this unique identifier. I would understand to have one if I could relate to other places where this identifier is shown. If the idea is to have that identifier so we can go to Datadog to find the entire related trace, then maybe this identifier can be the trace ID directly?

[Khoyo]

this identifier can be the trace ID directly

Do we have traceids when tracing isn't enabled? If not, maybe we should just specify it as some unique identifier, which may or may not be a trace id (and also, may or may not be a valid uuid too).

[leovalais]

I'm not against using trace IDs if we can have them when telemetry is disabled.
I'm not sure if it's concerning or not, but should we decide to do so, we'd leak some trace IDs to the frontend.

[leovalais]

After the discussion we had during the PIP, I moved this in the "Rejected ideas" section, I'll let you resolve if its ok 717e31d (#237)

[Khoyo]

I must have missed where we do rule on that in this document... :)

[leovalais]

Done in ec3e8d2 (#237)

[leovalais]

Thanks for all the corrections! I'll get back to this document when I have some time, hopefully in the next iteration :)

[leovalais]

I've added a bit of content, especially an implementation plan and details about how to forward Core errors.

[leovalais]

Thanks for the corrections!

[woshilapin]

Nice introducing some new sections about "Issues of the old system" or "Implementation plan".