Replies: 5 comments 1 reply
-
This was arbitrarily decided. From my observations, this isn't really necessary as I've never had a time sync issue (it has always succeeded with the GET request on the minute exactly), but I decided to keep it because it wouldn't hurt (and may help due to time sync issues other people potentially have).
You can do this and I don't think SW would reject the attempts since it is so close to check-in time. How many attempts does it take before completing the GET request?
No, there hasn't. |
Beta Was this translation helpful? Give feedback.
-
I had an instance running on Windows 11 today that I had changed to 7 seconds. I got B08. Just one data point. |
Beta Was this translation helpful? Give feedback.
-
It took 9 seconds for the GET request to go through for me. In those 9 seconds though, it made 5 requests, so increasing the number of seconds before the minute to start checking in most likely won't do much as it seemed to still fail until 1 or 2 attempts after the first five seconds. |
Beta Was this translation helpful? Give feedback.
-
Just adding an additional data point. Changed the setting to 10 seconds and got A22; HOWEVER, the 11/17/23 flight to DEN had 100 empty seats. Log shows the attempts started 10 seconds prior to check-in and was successful 8 seconds after check-in. |
Beta Was this translation helpful? Give feedback.
-
Primary residence (last check-in result): Xfinity 1Gbps, hard wire connection BTW, should have said this is V7.1 which is working great. |
Beta Was this translation helpful? Give feedback.
-
I have used V6.1 successfully at least 4 times recently and am glad I don't have to sit and stare at my clock and the SW website; however, each time the boarding slot issued has been in the mid to higher B category, a result similar to my past manual check-in experiences. This led me to poke around in the logs and code to see how/when the check-in process starts. I found the code segment and your impressively detailed comments where you show that the app hits the SW site 5 seconds before the actual check-in time to guard against near-end/far-end time sync issues. My log files show that the GET command is logged 5 sec before check-in and 5 seconds elapse after the check-in time before the POST command is logged and about 11 seconds elapse until the confirmation is logged. So my questions relate to that parameter. How did you decide on 5 sec? Can that be increased, say to 6, 7 or even 10 sec, without SW rejecting excessive attempts prior to check-in? I realize that sensitivity testing in this environment is difficult but has there been any feedback from other users on the effect of changing this parameter?
Beta Was this translation helpful? Give feedback.
All reactions