Skip to content
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

Conversation

woshilapin
Copy link
Contributor

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.

⚠️ Note that I targeted directly the branch of #9873

@woshilapin woshilapin requested a review from a team as a code owner December 4, 2024 14:10
@github-actions github-actions bot added the area:editoast Work on Editoast Service label Dec 4, 2024
@codecov-commenter
Copy link

codecov-commenter commented Dec 4, 2024

⚠️ Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 84.93151% with 11 lines in your changes missing coverage. Please review.

Project coverage is 38.23%. Comparing base (02ccfc8) to head (be49452).
Report is 10 commits behind head on hai/editoast-log-stdcm-requests.

Files with missing lines Patch % Lines
editoast/src/core/stdcm.rs 16.66% 5 Missing ⚠️
editoast/src/models/stdcm_log.rs 93.10% 2 Missing ⚠️
editoast/src/views/timetable/stdcm.rs 90.47% 2 Missing ⚠️
editoast/editoast_models/src/tables.rs 93.33% 1 Missing ⚠️
editoast/src/core/conflict_detection.rs 0.00% 1 Missing ⚠️

❗ 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              
Flag Coverage Δ
editoast 73.38% <84.93%> (-0.02%) ⬇️
front 20.18% <ø> (ø)
gateway 2.18% <ø> (ø)
osrdyne 3.28% <ø> (ø)
railjson_generator 87.49% <ø> (ø)
tests 87.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@leovalais leovalais left a 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;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Comment on lines +35 to +37
// 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.
Copy link
Contributor

@leovalais leovalais Dec 4, 2024

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point.

@hamz2a hamz2a force-pushed the hai/editoast-log-stdcm-requests branch from e37b50e to e9e81aa Compare December 4, 2024 15:32
@hamz2a
Copy link
Contributor

hamz2a commented Dec 4, 2024

As discussed, I have integrated the changes into the PR, thank you very much for the suggestions. @woshilapin @leovalais

@hamz2a hamz2a force-pushed the hai/editoast-log-stdcm-requests branch from e9e81aa to 2e01cb6 Compare December 4, 2024 15:40
@woshilapin
Copy link
Contributor Author

This work has been integrated into #9873, I'm closing it.

@woshilapin woshilapin closed this Dec 5, 2024
@woshilapin woshilapin deleted the wsl/editoast-log-stdcm-requests-one-function branch December 19, 2024 10:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:editoast Work on Editoast Service
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants