Fetch conflicts after train simulation update#16701
Conversation
Signed-off-by: achrafmohye <a.mohyeddine@gmail.com>
Pivouane
left a comment
Pivouane
left a comment
There was a problem hiding this comment.
LGTM, works fine, thank you 👍
| // we don't want to invalidate the train_schedule tags here to prevent multiple calls | ||
|
|
||
| getTimetableByIdConflicts: { | ||
| providesTags: ['conflicts'], |
There was a problem hiding this comment.
This removes the current tags, ['timetable']. This is an issue because deleteTrainSchedules is not the only request which should invalidate conflicts. For instance, updating a train schedule's path may also result in a new conflict or remove an existing conflict.
(Note, I don't understand why we need a new tag type.)
| }).unwrap(); | ||
|
|
||
| setTrainScheduleDepartureTime(trainScheduleId, newDeparture); | ||
| dispatch(osrdEditoastApi.util.invalidateTags(['conflicts'])); |
There was a problem hiding this comment.
This is doing manually something that rtk-query should be doing automatically. Do we have a good reason to do so?
| if (onProgressRef.current) onProgressRef.current(summaries); | ||
| if (loader.pending.length === 0) { | ||
| setAllSimulationsDone(true); | ||
| dispatch(osrdEditoastApi.util.invalidateTags(['conflicts'])); |
There was a problem hiding this comment.
Obtaining new simulations shouldn't invalidate any previously fetched conflicts.
Invalidating conflicts means that conflicts have changed. Obtaining simulations doesn't mutate any train schedule, so that can't invalidate conflicts.
3 participants
Closes #16347