-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
editoast: extract all the STDCM log logic into a function #9947
editoast: extract all the STDCM log logic into a function #9947
Conversation
Signed-off-by: hamz2a <[email protected]>
Signed-off-by: Jean SIMARD <[email protected]>
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## hai/editoast-log-stdcm-requests #9947 +/- ##
===================================================================
+ Coverage 38.21% 38.23% +0.01%
===================================================================
Files 992 993 +1
Lines 92158 92218 +60
Branches 1186 1186
===================================================================
+ Hits 35221 35261 +40
- Misses 56486 56506 +20
Partials 451 451
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great to keep the stdcm
handler as clean as possible! There's just a few things I'd leave in that handler ⬇️
use utoipa::ToSchema; | ||
|
||
use crate::core::stdcm::Request; | ||
use crate::core::stdcm::Response; | ||
use crate::models::prelude::*; | ||
use crate::views::Authentication; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A views
import in models
:/
Given how things are going, the authentication and authorization are likely to stay in views
and in a dedicated crate. The models
"crate" won't probably know about that layer. Wdyt about taking an Option<i64>
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, so agreed. I really quickly prototyped this solution (maybe I should have opened a draft). This is one thing to improve for sure.
// We just don't await the creation of the log entry since we want | ||
// the endpoint to return as soon as possible, and because failing | ||
// to persist a log entry is not a very important error here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this comment stay near the spawn
? It mentions an "endpoint" and awaiting or not the return value is a decision for the caller.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point.
e37b50e
to
e9e81aa
Compare
As discussed, I have integrated the changes into the PR, thank you very much for the suggestions. @woshilapin @leovalais |
e9e81aa
to
2e01cb6
Compare
This work has been integrated into #9873, I'm closing it. |
Here is a suggestion to put everything inside a single function and extract all this weird debugging logic as far as possible of the main business logic that is in STDCM endpoint.