makeFetchCheckinDataAttempts is taking more than 250 ms between request
aaron-pham opened this issue · 3 comments
Hey,
One thing that I'd like in an automated checkin is knowing that it is faster than me as a human. I notice that in the logs for successful checkins, we are retrying about every 1200 ms instead of 250 ms.
I assume the method will wait for a response each time, before retrying.
This may cause the checkin to be slightly slower than a human (I'll be testing this soon! Have a flight coming up with friends and I'll see who gets the better seat!)
I don't really understand how this function works, but is there anyway we can improve it to actually retry every 250ms?
Logs below for a checkin, with the timestamps.
2022-02-08T09:54:55.103-08:00 2022-02-08T17:54:55.103Z e7ae96a5-bab7-43ad-9eda-489fa7faee43 INFO Starting fetch checkin data attempts at February 8, 2022, 5:54:55 PM UTC
2022-02-08T09:54:56.335-08:00 2022-02-08T17:54:56.335Z e7ae96a5-bab7-43ad-9eda-489fa7faee43 INFO Failed on attempt 1 of 79 at February 8, 2022, 5:54:56 PM UTC with error: {"code":400308191,"message":"Sorry! This reservation is not eligible for check in.","messageKey":"ERROR__AIR_TRAVEL__BEFORE_CHECKIN_WINDOW","header":null,"httpStatusCode":"BAD_REQUEST","requestId":"9FC88DE0-8907-11EC-BE80-6DDA96DCCD60:HLNvijr2Rd-J0_jN4wYfdQ:mweb","infoList":[]}
2022-02-08T09:54:57.489-08:00 2022-02-08T17:54:57.489Z e7ae96a5-bab7-43ad-9eda-489fa7faee43 INFO Failed on attempt 2 of 79 at February 8, 2022, 5:54:57 PM UTC with error: {"code":400308191,"message":"Sorry! This reservation is not eligible for check in.","messageKey":"ERROR__AIR_TRAVEL__BEFORE_CHECKIN_WINDOW","header":null,"httpStatusCode":"BAD_REQUEST","requestId":"9FC88DE0-8907-11EC-BE80-6DDA96DCCD60:igJRoWOAR9mhm5IPopOfRw:mweb","infoList":[]}
2022-02-08T09:54:58.986-08:00 2022-02-08T17:54:58.986Z e7ae96a5-bab7-43ad-9eda-489fa7faee43 INFO Failed on attempt 3 of 79 at February 8, 2022, 5:54:58 PM UTC with error: {"code":400308191,"message":"Sorry! This reservation is not eligible for check in.","messageKey":"ERROR__AIR_TRAVEL__BEFORE_CHECKIN_WINDOW","header":null,"httpStatusCode":"BAD_REQUEST","requestId":"9FC88DE0-8907-11EC-BE80-6DDA96DCCD60:W8DxRxxsR0-aK4rffe16sg:mweb","infoList":[]}
2022-02-08T09:55:00.183-08:00 2022-02-08T17:55:00.183Z e7ae96a5-bab7-43ad-9eda-489fa7faee43 INFO Failed on attempt 4 of 79 at February 8, 2022, 5:55:00 PM UTC with error: {"code":400308192,"message":"This flight is currently not ready for check-in. Please try again momentarily.","messageKey":"ERROR__AIR_TRAVEL__NOT_OPEN","header":null,"httpStatusCode":"BAD_REQUEST","requestId":"9FC88DE0-8907-11EC-BE80-6DDA96DCCD60:OhvnWYMKSPaG8oYA3_XfpQ:mweb","infoList":[]}
2022-02-08T09:55:01.341-08:00 2022-02-08T17:55:01.341Z e7ae96a5-bab7-43ad-9eda-489fa7faee43 INFO Failed on attempt 5 of 79 at February 8, 2022, 5:55:01 PM UTC with error: {"code":400308192,"message":"This flight is currently not ready for check-in. Please try again momentarily.","messageKey":"ERROR__AIR_TRAVEL__NOT_OPEN","header":null,"httpStatusCode":"BAD_REQUEST","requestId":"9FC88DE0-8907-11EC-BE80-6DDA96DCCD60:8yIM279MSZeivl6jx-2UdA:mweb","infoList":[]}
2022-02-08T09:55:02.634-08:00 2022-02-08T17:55:02.633Z e7ae96a5-bab7-43ad-9eda-489fa7faee43 INFO Failed on attempt 6 of 79 at February 8, 2022, 5:55:02 PM UTC with error: {"code":400308192,"message":"This flight is currently not ready for check-in. Please try again momentarily.","messageKey":"ERROR__AIR_TRAVEL__NOT_OPEN","header":null,"httpStatusCode":"BAD_REQUEST","requestId":"9FC88DE0-8907-11EC-BE80-6DDA96DCCD60:r73KbXEeRVqib9ZWKsTj8Q:mweb","infoList":[]}
2022-02-08T09:55:03.877-08:00 2022-02-08T17:55:03.876Z e7ae96a5-bab7-43ad-9eda-489fa7faee43 INFO Failed on attempt 7 of 79 at February 8, 2022, 5:55:03 PM UTC with error: {"code":400308192,"message":"This flight is currently not ready for check-in. Please try again momentarily.","messageKey":"ERROR__AIR_TRAVEL__NOT_OPEN","header":null,"httpStatusCode":"BAD_REQUEST","requestId":"9FC88DE0-8907-11EC-BE80-6DDA96DCCD60:o0w862NyQ3msfktAcawv9Q:mweb","infoList":[]}
2022-02-08T09:55:05.209-08:00 2022-02-08T17:55:05.209Z e7ae96a5-bab7-43ad-9eda-489fa7faee43 INFO Failed on attempt 8 of 79 at February 8, 2022, 5:55:05 PM UTC with error: {"code":400308192,"message":"This flight is currently not ready for check-in. Please try again momentarily.","messageKey":"ERROR__AIR_TRAVEL__NOT_OPEN","header":null,"httpStatusCode":"BAD_REQUEST","requestId":"9FC88DE0-8907-11EC-BE80-6DDA96DCCD60:hHu9X5xoTQ6CeL-wLvnrPg:mweb","infoList":[]}
2022-02-08T09:55:06.904-08:00 2022-02-08T17:55:06.903Z e7ae96a5-bab7-43ad-9eda-489fa7faee43 INFO Checking in at February 8, 2022, 5:55:06 PM UTC
2022-02-08T09:55:08.991-08:00 2022-02-08T17:55:08.991Z e7ae96a5-bab7-43ad-9eda-489fa7faee43 INFO Checkin succeeded
The more I look at it, and @pyro2927's version, I think we send the request, wait for a response, if it's not a success response, wait 250ms and try again.
Thinking about this, do we really need to wait 250ms between each request? The response will always take time to get to us, so that should give enough buffer time between request to have 20 or more seconds of attempts.
Currently playing around with this, and if we attempt to do a check-in on an invalid time/confirmation number (Manually sent the payload to my lambda for testing), for all 80 attempts to fail, we attempt to check-in for a total of about 1 minute.
If we turn the retry down to 1ms instead of 250ms, we attempt to check-in for a total about 30-35 seconds. I'm going to create this change on my fork, let me know if you'd like a PR for this as well.
This is a good catch. The current implementation doesn't really consider the amount of time that it takes for the request to come back. I'm a little wary of setting the retry to 1 ms because we'd be relying on the airline's API to have a delay. While like you said, it should work most of the time, I'd rather not rely on their API's performance to give us a large enough checkin window. What if instead, we don't wait for the requests to come back? Simply send our requests on an interval we define and stop as soon as one of them comes back with a 200-level response. This is something that a human cannot do, but which the asynchronous nature of Node.js makes relatively simple.