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

lmr: time window for possible simulations is incorrect #10838

Closed
maelysLeratRosso opened this issue Feb 18, 2025 · 1 comment · Fixed by #10866
Closed

lmr: time window for possible simulations is incorrect #10838

maelysLeratRosso opened this issue Feb 18, 2025 · 1 comment · Fixed by #10866
Assignees
Labels
area:editoast Work on Editoast Service from:users Something reported directly by the users kind:bug Something isn't working module:stdcm Short-Term DCM severity:critical Critical severity bug

Comments

@maelysLeratRosso
Copy link

What happened?

Now : one can start a simulation with a departure between J+1 17h and J+7 (anytime), no matter when the simulation is done.

What did you expect to happen?

The expected behavior is :
Before 17h, one can start a simulation between J+1 and J+7 (anytime for both)
After 17h, one can start a simulation between J+2 and J+7 (anytime for both)

How can we reproduce it (as minimally and precisely as possible)?

On which environments the bug occurs?

Recette (SNCF)

On which browser the bug occurs?

Google Chrome

OSRD version (top right corner Account button > Informations)

8aaefd4

@maelysLeratRosso maelysLeratRosso added kind:bug Something isn't working area:front Work on Standard OSRD Interface modules area:editoast Work on Editoast Service module:stdcm Short-Term DCM severity:critical Critical severity bug from:users Something reported directly by the users labels Feb 18, 2025
@bloussou
Copy link
Contributor

Meeting 18/02/2025 @flomonster @clarani @bloussou @elise-chin

Ideas

handle this in osrd-data

pros

  • Quick and dirty

cons

  • Shady backend feature
  • We have to decorrelate basic caching and stdcm search env change since we don't know basic caching duration (between 20min and 1h)
  • probably too much logic in private code for a feature that should be public

handle this in editoast

pros

  • history of search envs
  • no need to change osrd-data logic
  • strong resilience to the switch 16h59 -> 17h
  • end of stdcm search env with 1 row table in editoast datamodel

cons

  • more complexity

✅ We decided solution 2 is better.

Refinement

Editoast

id: 0
electrical_profile_set_id: 0
infra_id: 0
search_window_begin: "2025-02-18T00:00:00Z"
search_window_end: "2025-02-24T23:59:59Z"
temporary_speed_limit_group_id: 0
timetable_id: 0
work_schedule_group_id: 0
# New fields
enabled_from: "2025-02-17T17:00:00Z"
enabled_to: "2025-02-18T17:00:00Z"

Adapt GET /search_env and POST /search_env:

  • GET:
    • Take the env that is in the enabled env and if there are multiple just take the newer.
    • If no env is enabled then take the most recent enabled_to
  • POST: keep it stupid
    • Just check enabled_from < enabled_to
    • in dev mod set enabled_* in the past and far future

Migration:
Set the dates of enabled_* in the past, if there is only 1 env this one will be picked with the fallback logic.

osrd-data

Change the calls to POST /stdcm_search_env with the correct enabled_*

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 from:users Something reported directly by the users kind:bug Something isn't working module:stdcm Short-Term DCM severity:critical Critical severity bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants