From 46336d88a121802dc94baed25f362f51a4b6e91c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Valais?= Date: Wed, 27 Nov 2024 09:14:18 +0100 Subject: [PATCH] Update content/docs/reference/design-docs/editoast-errors/_index.en.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Serge Croisé --- content/docs/reference/design-docs/editoast-errors/_index.en.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/reference/design-docs/editoast-errors/_index.en.md b/content/docs/reference/design-docs/editoast-errors/_index.en.md index 1517ec3db..0d76ba22a 100644 --- a/content/docs/reference/design-docs/editoast-errors/_index.en.md +++ b/content/docs/reference/design-docs/editoast-errors/_index.en.md @@ -12,7 +12,7 @@ weight: 80 - We can't track at compile-time which errors are returned by each function: that means that we don't know for sure which errors an endpoint can return (without careful manual investigation at least...) - Consequently, we hardly can declare in the OpenApi file what errors an endpoint precisely returns, degrading the editoast API quality - The frontend still requires editoast to declare all its errors though, to ensure they are translated properly. To achieve that we dynamically collect each `EditoastError` using the crate `inventory`. All the error descriptions collected are then transformed into OpenAPI schemas procedurally. On top of being a Rust antipattern (collecting state in proc-macros), this is complex to maintain on both editoast and frontend sides. - - Not having each endpoint linked to the list of errors it can raises also prevents the frontend easily handle errors properly. + - Not having each endpoint linked to the list of errors it can raise, also prevents the frontend easily handling errors properly. - It's still unclear how we should expose errors from Core. # Goals