mirror of
https://github.com/cpvalente/ontime.git
synced 2026-08-06 16:03:52 +00:00
Claude
5b30f522aa
The server computed rundown/group expected end times as `expectedStart + duration`, ignoring `countToEnd`. For a count-to-end last event running in overtime this pushed the projected end far past (or before) its fixed end time, producing nonsensical values (e.g. a negative expected rundown end) and leaving group/flag readouts stuck on "due". It also never broke the link chain after a count-to-end event, unlike the client. A count-to-end event ends at its fixed end time regardless of preceding overtime (matching `getExpectedFinish` for the running timer), so its expected end should pin to the planned end and absorb the accumulated offset. - add shared `getExpectedEnd` helper in ontime-utils that pins count-to-end events to their planned end - use it in `getExpectedTimes` for both rundown and group end - break the `isLinkedToLoaded` chain after a count-to-end event in `loadGroupFlagAndEnd`, mirroring the client metadata logic - delegate the client's `getExpectedTimesFromExtendedEvent` to the shared helper to remove the duplicated formula that caused the drift - add unit and runtime-state tests covering overtime absorption and the chain break Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ACGuFWt5aN7Fv3AkYXgxLm