Failed to check in due to local time being ahead about auto-southwest-check-in HOT 17 CLOSED

Haha, well glad we helped find a "bug"! I'll update to 7.3 and let you know how it goes in a few weeks.

from auto-southwest-check-in.

Hmmm, I reran the bot and it actually succeeded the next time. Wonder if there should be some retry mechanism?

from auto-southwest-check-in.

Hey, thanks for filing this issue. Someone else also reached this issue here. A Bad Request 400 means that there was a client-side error, but I'm not really sure what went wrong because it worked when you ran it again. Perhaps it is something on Southwest's side or has to do with #230 (although this isn't with Docker).

Wonder if there should be some retry mechanism?

The check-in will try 20 times (with the logs, you can see it took 35 seconds to fail) when it encounters an unsuccessful request but its unclear why the issue is not reproducible when you restart the script.

from auto-southwest-check-in.

any ideas for logging to help debug the issue? I have some more flights coming up in 2 weeks.

from auto-southwest-check-in.

Could you send the log of the run that failed (in the logs/ folder)? There should be more output in between Making GET request to check in and the Bad Request 400 which logs the response body it received when it failed and I'm not sure why that didn't show up.

from auto-southwest-check-in.

Hmm this is all I see in those logs:

2024-03-03 08:14:55 DEBUG Process-4:1[checkin_handler:94]: Acquiring lock...
2024-03-03 08:14:55 DEBUG Process-4:1[checkin_handler:96]: Lock acquired
2024-03-03 08:14:55 DEBUG Process-4:1[checkin_scheduler:50]: Refreshing headers for current session
2024-03-03 08:14:55 DEBUG Process-4:1[webdriver:106]: Starting webdriver for current session
2024-03-03 08:15:01 DEBUG Process-4:1[webdriver:122]: Using browser version: 121.0.6167.189
2024-03-03 08:15:01 DEBUG Process-4:1[webdriver:126]: Loading Southwest Check-In page
2024-03-03 08:15:07 DEBUG Process-4:1[webdriver:64]: Waiting for valid headers
2024-03-03 08:15:07 DEBUG Process-4:1[webdriver:155]: Waiting for headers_set to be set
2024-03-03 08:15:08 DEBUG Process-4:1[webdriver:159]: headers_set set successfully
2024-03-03 08:15:10 DEBUG Process-4:1[checkin_handler:99]: Lock released
2024-03-03 08:15:10 DEBUG Process-4:1[checkin_handler:103]: Sleeping until check-in: 1784 seconds...
2024-03-03 08:44:55 DEBUG Process-4:1[checkin_handler:124]: Attempting to check in
2024-03-03 08:44:55 DEBUG Process-4:1[checkin_handler:138]: Making GET request to check in
2024-03-03 08:45:30 DEBUG Process-4:1[checkin_handler:147]: Failed to check in. Error: Bad Request 400. Exiting
2024-03-03 08:45:30 DEBUG Process-4:1[notification_handler:111]: Sending failed check-in notification...

from auto-southwest-check-in.

What operating system are you on?

from auto-southwest-check-in.

windows 11 pro

Version 10.0.22621 Build 22621

from auto-southwest-check-in.

Ah, the module that logs the requests was not updated when I fixed logging on Windows, so it hasn't been logging this whole time on Windows...ha. Well, that will be fixed in v7.3. If you (or someone else) gets this issue again, the debug output should be a lot more helpful.

from auto-southwest-check-in.

I am having a very similar issue

Here is my dump from the log file

this was working for me too then suddenly stop. I upgrade to latest version to see if it would resolve the issue.

from auto-southwest-check-in.

@Malklor the issue you are facing is #230 (even if you aren’t using Docker). This issue is about receiving a Bad Request 400 during check-in.

from auto-southwest-check-in.

I think I found the reason. My windows time was not synced. About 1 minute off. Think this isn't an issue and was due to environment. Kind of silly windows doesn't have an option to stay in-sync for time, lol.

from auto-southwest-check-in.

I think I found the reason. My windows time was not synced. About 1 minute off. Think this isn't an issue and was due to environment.

That would explain the 400 status code. If the logging was working at this time, it probably would have shown “too early to check in”.

Do you want to close this issue as a user error or do you have an idea of a programmatic way of solving it? One option could be to communicate with an external time server, but that seems overkill. Detecting that it’s too early won’t do much too because, if the time is wrong, the script won’t know how off the time is.

from auto-southwest-check-in.

Hey @aaron-pham, do you have any thoughts on my reply above?

from auto-southwest-check-in.

I kind of like checking the timeserver for our time - we're already making network calls and whatnot. It would be a nice layer of protection but possibly adds some complexity. I'm pretty busy right now - so maybe we can close this and perhaps look into this another time.

A basic thing would be checking & logging it which could help with debugging, but as you said the 400s would probably give you an idea. It would be slightly hard to track down without explicit logs still since they would show the "proper" time.

from auto-southwest-check-in.

I have a working implementation of using an NTP server (and falling back to getting the system’s local time on error) on my local machine. It actually is very simple to implement because the ntplib package can be used for the bulk of the actual request and parsing.

I’ll implement it on another branch so it can be tested in action. This feature may also help fix #252.

from auto-southwest-check-in.

I decided to merge this into the develop branch as I was able to test it (not a check-in, but the NTP fetch is used in other places so I tested through that). Thanks for the suggestion @aaron-pham. This should fix the issue you received in future check-ins.

from auto-southwest-check-in.