feat: strikethrough original dest/origin stations when changed - #562
Conversation
Includes DB changes, OCS message handling changes, and UI changes
| destination_station: | ||
| fragment("COALESCE(?, EXCLUDED.destination_station)", trip.destination_station), |
There was a problem hiding this comment.
question: is setting destination_station on a TSCH DST conflict a no-op? i.e. can this line be left out, or does the set have to cover all columns?
There was a problem hiding this comment.
we might be able to get away with leaving it out. let me do some testing.
| } = queried | ||
| end | ||
|
|
||
| test "TSCH_NEW with changed endpoints preserves scheduled stations and records updates" do |
There was a problem hiding this comment.
question: Is this test case redundant given that the previous upsert test case also changes the endpoints?
| # Scheduled endpoints from setup are preserved; new values from | ||
| # the TSCH_NEW go to the updated columns because they differ. | ||
| origin_station: "ORIGIN_STATION", | ||
| origin_station_updated: "ORIGIN_STA", | ||
| destination_station: "DESTINATION_STATION", | ||
| destination_station_updated: "DEST_STA" |
There was a problem hiding this comment.
thought/suggestion: I'm not 100% sure which way I'd prefer to handle this, but I'm actually thinking that it may make sense for a TSCH_NEW to update the scheduled endpoints and nil out any updated ones? The reasoning is that semantically I think a TSCH_NEW is meant to represent loading a fresh trip into the schedule (either from HASTUS or as a one-off added by the dispatcher). So in theory, we should not generally receive repeat TSCH_NEWs, except for cases of Kinesis replay.
But imagine for some reason that OCS decided to reload the schedule for the current service date after the usual batch of TSCH_NEW messages at 2am. (For example, if by some error the wrong schedule from HASTUS got loaded). I would expect that if a trip UID got reused (very possible) then the new TSCH_NEW would represent the scheduled state without overrides, and it would be incorrect to show strikethrough based on the prior value.
3 participants
Includes DB changes, OCS message handling changes, and UI changes
Asana Task: 🍫 Strikethrough departure/arrival in orbit sidebar when changed
Does not include accurate design since that's dependent on the tailwind and sidebar redesign work.
Checklist
(x)Light & dark mode(x)Desktop & mobile sizes( )Chromium(x)Firefox( )Safari(x)Commits free of internal data(x)PR description free of internal data(x)Logging free of internal data(x)Has tests( )Doesn't need tests( )Tests deferred (with justification)( )Okayed the plan for the feature (e.g. the design files, or the Asana task)( )Reviewed the feature as implemented (e.g. on dev-green, or saw screenshots)( )No review needed