Doesn't handle changed flights #199
Comments
|
Thank you for reporting this. This bug is actually a regression from v6.1 when I changed the script to check if two flights were equal by their flight number. However, it didn't handle the departure time changing. Now this is fixed by checking both. In a scenario like this, the old flight (before the change) would be canceled and the new flight (after the change) would be scheduled. I also added a test to ensure this bug will be caught later down the line.
My fix still doesn't handle the issue of changing it within 24 hours of the flight (I actually forgot about this when pushing the fix). I can definitely add a check to reprocess the reservation again right before this message. The other option would be to just lower the retrieval interval--which seems worse. Let me know your thoughts on this. |
|
I think lowering the retrieval interval isn't a great answer, since you can never really get it reasonably "low enough". I think reprocess the reservation at the 30 minute mark before the final scheduling is basically as good as you can get. |
|
I agree with not lowering the retrieval interval. TL;DR for the below: Longer explanation: It actually is a lot more complicated to try to reprocess the reservation 30 minutes before check-in. The reasoning is that, once a check-in is scheduled, it is put into a separate process. This means that, once it ends, everything created from it ends as well. Triggering a reprocessing of a reservation may detect a change like this and set up the schedule for the new flight. However, once the original flight's check-in ends or is canceled (which would be done through the script as it would see that flight is no longer valid), all new flights scheduled like this would die. Due to these issues, I think your second solution would actually work better. Due to the changes I made above, the next time the flight retrieves the reservations, a new flight would be scheduled and the old flight would be canceled. Since the change happened within 24 hours of the old flight's check-in, the old flight would still attempt to check in and fail. In this case, a notification can be sent with something along the lines of The only issue I can see with this is that, if the retrieval interval is high--say 48 hours--it wouldn't schedule the new flight to check in if it was changed 1.5 days before the check-in (as it was in your case). I would argue that this is more of a user issue though as they shouldn't be configuring a high retrieval interval if they change flights right before the check-in. |
|
I've been thinking about this a bit more and there are two scenarios I can think of that are affected in this issue:
In this case, the script would fail for the first flight (as it was changed and is too early to check in) and not even schedule the next flight (the next retrieval has not been triggered yet). I don't believe this is really an issue though since this situation is so rare (the average user will never have this happen). The workaround here--in the case that someone does frequently do this for some reason--is to lower the retrieval interval. That is partly the purpose of having a configurable retrieval interval, so someone can adjust it depending on how often they schedule/change flights. With the way the script is structured, checking right before a flight checks in is infeasible. Majorly refactoring it to accommodate for this situation that affects a very small percentage of users (if any) doesn't seem worth it. Any suggestions on how to implement this cleanly are welcome.
The old flight would fail to check in, as it is too early (the notification can be adjusted to say |
I can imagine this actually isn't too rare. Lets say I have a noon flight, and the day before the flight I reschedule from noon to 5pm. I hadn't appreciated that it's an actual process that's spawned for each checkin. I can think of 2 ways to solve this:
Both work better with my idea of a fixed regular processing time (say 3am). |
|
Thanks for the detailed response. I like solution 2 and will implement it when I have the time. I’m not very familiar with |
|
Came here to open an issue and saw the issue already exists! Just here to state I encountered the same thing, guess it's not that crazy of an edge case. My experience: On Sunday AM (>24 hour from flight on Monday), rescheduled flight from Monday PM to Tuesday PM. And then on Monday, it did not check me in for the Tuesday flight. I guess a refresh of the flight data on failure would help solve my case (but would not help solve the case of moving the flight up a few hours earlier). |
|
This was not totally fixed in the commit above |
Version
Auto-Southwest Check-In v7.1
Browser Version
120.0.6099.199
Description
The script was already running, with the every-24-hour check happening around noon.
Sunday evening I changed my flight from Tuesday to Wednesday morning.
Monday morning it tried to check into the flight which failed. The failure email just says Reason: Bad Request 400.
To Reproduce
Change a flight after the script has already scheduled it.
I'm not sure if changing the flight before or after the every-24-hour check makes a difference. I also changed a later flight and during the 24-hour check I do not see a "Scheduling check-in for current flight" that updates
Expected Behavior
I see 2 improvements here:
Relevant logs and program output
Additional context
No response
The text was updated successfully, but these errors were encountered: