Would new flights be added automatically?

[austinliuu]

Hi @jdholtz, just curious, if I use the script to sign in my account and left it running, let's say later I booked some new flights , would the new flights be scheduled for check-ins automatically, or I have to kill and restart?

[jdholtz]

That is a feature I want to add (which is why I added the ability to log into your account). Then the script would essentially be able to automatically schedule check-ins without any human intervention.

However, it would be very hard to test in a real life scenario. It shouldn’t actually be hard to implement though, so I can look into adding that soon.

[austinwang14]

However, it would be very hard to test in a real life scenario.

I think you could definitely test it. Book a couple fully refundable flights. Then, you would just have to remember to cancel right after confirming you've checked in.

[austinliuu]

However, it would be very hard to test in a real life scenario.

I think you could definitely test it. Book a couple fully refundable flights. Then, you would just have to remember to cancel right after confirming you've checked in.

But can you cancel for refund after you have checked in?

[jdholtz]

Yes, you should be able to cancel it for a full refund (I asked Southwest about this a while back).

I haven’t had time to work on this feature lately, but hopefully I will soon.

[jdholtz]

Hey. I haven’t had much time to work on this, but I have done some work on it. You can check the progress in the auto_scheduling branch. Hopefully I’ll have some more time in November to finish this feature before the holiday season.

[sdstolworthy]

@jdholtz I haven't had a chance to review your branch, but on my flight last night I was looking through the codebase hoping to get together a solution to tackle this. I put together these notes.

Proposed Refactors

1. Account will be decomposed into distinct FlightRetriever classes

Currently, Account's core responsibility is fetching a list of flights.
However, the class acts differently depending on which parameters it is instantiated with.
For example, it seems that the method get_info on the WebDriver class,
invoked by get_flights on the Account class, does not work unless a username and password have been provided.
Similarly, get_checkin_info on the Account class can only be invoked if first_name and last_name are set defined within the class instance.
Currently, those values are only ever set in the constructor, which implies that it is only intended to be used in "reservation" mode.

These classes could be decomposed into FlightRetriever classes, which expose a common method, get_flights, which returns a list of flights.

For example, an AccountFlightRetriever class could handle retrieving flights when a username/password is supplied, whereas a ReservationFlightRetriever could handle fetching flights where only a first name, last name, and confirmation number are provided.

2. Flight will become a class without side effects, purely a data class

Currently, flight handles logic that is not inhertently related with the flight data itself.
It handles logic around scheduling checkins and sending messages with results

The proposed refactor is to remove all check in and messaging logic from the flight class and create a new class, CheckinScheduler.

The CheckinScheduler class will receive a FlightRetriever class, and will be able to poll that class for new flights and schedule checkins for those flights.

Account will be refactored to be two different classes that extend a base FlightRetriever class.

A CheckInHandler class will handle much of the side effect logic currently handled in the flight class.

FlightRetriever:

• get_flights()

CheckinHandler:

• __init__(FlightRetriever)
• check_in()

Checkin Handler would handle the logic in flight.py:

• _wait_for_check_in
• _set_check_in

I think it would solve some of the challenges that exist right now. It might be more extensive than desired though.

[jdholtz]

@sdstolworthy this sounds great! I don’t think it would be too complicated because the logic would be fairly simple. The flow would also make a lot more sense with this framework. You can start implementing this if you want/have the time (I’m a little short on time atm).

One thing to note: The account first_name and last_name are set after logging in (as the name is what is needed to check in). That logic can be found in the webdriver function get_account_info.

[jdholtz]

Hey @austinliuu and @sdstolworthy. I have finished my refactor of the script which adds this new feature. Please let me know what you think (especially @sdstolworthy as many of your proposed refactors were done) and it would be great if you could test it out (I've tested it locally, but of course it would be better to get outside verification).

[austinliuu]

I rebuilt the docker image and logged in using my account. After booking a new flight, I can see it successfully picked it up. Thanks for the good work!

[austinliuu]

Just be curious, what happen if I later cancel my flight? Would the scheduled check-in be cancelled also?

[jdholtz]

Not currently. I think it’ll still attempt to check in and fail. I’ll put that on the to-do list.

I can probably also solve flight time changes by solving this issue (currently, if a flight is scheduled and it’s time changes, a new checkin will be started but the old one won’t be stopped).

[jdholtz]

Added in #25