Skip to content

front: fix origin arrival update time propagation + refactor time propagation#16231

Merged
Synar merged 3 commits intodevfrom
ali/fix-refactor-propagate-time-expurged
Apr 20, 2026
Merged

front: fix origin arrival update time propagation + refactor time propagation#16231
Synar merged 3 commits intodevfrom
ali/fix-refactor-propagate-time-expurged

Conversation

@Synar
Copy link
Copy Markdown
Contributor

@Synar Synar commented Apr 13, 2026

Close #16164

Edit: I think my last commit was way over engineered, and there is a much simpler way. Pushed as a fixup.

(D -> D+1 changes are still not handled well, but the exact same issue seems to exist for non origin steps)

@Synar Synar requested a review from a team as a code owner April 13, 2026 20:27
@github-actions github-actions Bot added the area:front Work on Standard OSRD Interface modules label Apr 13, 2026
@Caracol3
Copy link
Copy Markdown
Contributor

Thanks for the fix !
There is still something weird in the origin behavior.
When editing the origin's arrival time and then validating a requested arrival on another waypoint, the origin reverts to its initial time.

Enregistrement.de.l.ecran.2026-04-15.a.14.56.21.mov

Comment thread front/src/modules/timesStops/helpers/timePropagation.ts
Copy link
Copy Markdown
Contributor

@SharglutDev SharglutDev left a comment

Choose a reason for hiding this comment

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

Lgtm and tested, nice clean up !

Note

Seems like it's orthogonal to this PR but the optimistic update doesn't work well for the start time when propagation "toBeginning". On the video below, we can see a small delay before it's updated.

Enregistrement.de.l.ecran.2026-04-17.a.10.31.08.mov

Synar added 2 commits April 20, 2026 16:23
Factoring the logic together will enable us
to more easily add the special case for the origin,
and makes the logic of the function more apparent.

Signed-off-by: Alice Khoudli <alice.khoudli@polytechnique.org>
This change will both make handling the other cases than atThisWaypoint easier and DRYer,
but also make the time propagation of the origin case naturally work for other callers of propagateTime,
such as buildEditsForUpdate which creates the temporary state before the response from the back is received.

Signed-off-by: Alice Khoudli <alice.khoudli@polytechnique.org>
@Synar Synar force-pushed the ali/fix-refactor-propagate-time-expurged branch from 5c8c8f9 to f3a4e63 Compare April 20, 2026 14:23
Signed-off-by: Alice Khoudli <alice.khoudli@polytechnique.org>
@Synar Synar force-pushed the ali/fix-refactor-propagate-time-expurged branch from f3a4e63 to dff4374 Compare April 20, 2026 14:23
@Synar Synar added this pull request to the merge queue Apr 20, 2026
Merged via the queue into dev with commit a91db75 Apr 20, 2026
30 checks passed
@Synar Synar deleted the ali/fix-refactor-propagate-time-expurged branch April 20, 2026 16:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:front Work on Standard OSRD Interface modules

Projects

None yet

Development

Successfully merging this pull request may close these issues.

New schedule sheet : Propagation from first line does not work as expected

3 participants