What is the workflow if a fare difference is found?

[natecodes]

Found lower fare of -39 USD for flight XXXXXX from 'A' to 'B' on 2024-06-18 5:30 PM PDT for FIRST LAST!
Manage your reservation here: https://mobile.southwest.com/view-reservation

Is it up to the user to go onto Southwest and refare it, or can the script do it?

[babehboi]

You would need to go on and "refare" it.

I think it gets a little complicated later on if you have multiple fares and who booked it and by what means.

Plus the question is is that what you want? And if you already checked in and found a lower fare do you want it to take over?

As much as it would be nice, I've found issues when doing it especially if it's only checking reservation numbers and doesn't have the full login info...

[jdholtz]

Adding on to @babehboi, I didn't add an automatic way to book a lower fare because I didn't want to have the script need to deal with doing actions that are potentially disruptive to a user. I think it's a good compromise and doesn't have a chance of going against what a user wants (misconfiguration, bug in the script, etc.). If there is an automatic rebooking, it gets complicated very quickly, as pointed out above.

[dmytrokoren]

Adding on to @babehboi, I didn't add an automatic way to book a lower fare because I didn't want to have the script need to deal with doing actions that are potentially disruptive to a user. I think it's a good compromise and doesn't have a chance of going against what a user wants (misconfiguration, bug in the script, etc.). If there is an automatic rebooking, it gets complicated very quickly, as pointed out above.

To add to this statement. It's super easy to rebook with lower fair with southwest. Plus the script tells you which fair you need to rebook to save. I have fair check running every 8 hours basically 3 times per 24hrs. I read on southwest forum they said prices tend to change 3 times per 24hrs... just my two cents )

[natecodes]

Is there a way to run the script in a lighter mode where you only need fare check and not check in scheduling? I'm not sure if it's less network-intensive since I'd imagine the reservation lookup is only done once for both fare check and check-in schedule.

Use case is that my flight is in 30 days, I know I don't need to schedule the check in, I just want to see if there was a fare drop.

[jdholtz]

Is there a way to run the script in a lighter mode where you only need fare check and not check in scheduling?

There is not. However, one of the requests the fare checker makes is the same request as the check-in scheduling (this can be made into one request for both, but there would need to be proof that having one less request is worth it over the complexity of doing so). Overall, I doubt it makes much of an impact at all as the fare checker makes 3 requests for each flight so overall you would be making a total of 4 requests (3 for the fare checker and 1 for the check-in scheduler).

Because multiple flights/reservations can be checked, another approach that can be worked on (and already is to avoid 403s and 429s) is to make the script handle large amounts of requests better. If there's five flights, a total of 20 requests would be made and reducing it to 15 definitely would be an improvement in speed and network load, but it is still a lot of requests either way. A fairly large refactor would need to be done to make this possible and that's definitely an area for improvement in the future.

[natecodes]

When you say "make the script handle large amounts of requests better", how is that done?

[jdholtz]

When you say "make the script handle large amounts of requests better", how is that done?

Right now, more 403s and 429s are occurring as the script handles more reservations and accounts. It's probably due to some type of rate limiting done by Southwest or just a higher chance of detection due to more flights being handled.

A few people have been doing work to see how to improve this. One strategy is picking a random time between 1-5 minutes in between checking fares/flights for other reservations. However, we haven't achieved a strategy that we know works well yet.

[jdholtz]

A fairly large refactor would need to be done to make this possible and that's definitely an area for improvement in the future.

Was happily wrong on this. The improvement was simple to make, definitely makes a difference in speed (and hopefully reduces 403/429 errors due to less requests being sent), and will be in the next release.

[jdholtz]

FYI, I have added a TODO to use the reservation information retrieved for check-in scheduling for fare checking as well which will reduce each fare check by 33% (1 request per flight).

[jdholtz]

Just added a cache for the reservation info. Now, the fare checker only needs to make 2 new requests instead of 3 and takes advantage of the info retrieved from the checkin scheduler. Therefore, turning of check-in scheduling and only doing fare checking will make no difference in the amount of requests being sent.