403 and 429 Errors Thread #277
Comments
|
Macbook M1 no docker 'Too Many Requests' error only with logins, not reservations (see #277 (comment)) LOG |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
I am using the latest develop for several upcoming flights and I have noticed the following on startup scheduling the checkin...
Will post updates when checkin time comes Error I get from the docker image is... |
|
@mickgiles the logs for the develop image should show |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
using this image most succeeded but 1 reservation failed with the following logs Logsauto-southwest | 2024-07-02 02:18:39 DEBUG Process-7[checkin_scheduler:79]: Retrieving reservation information |
This comment was marked as resolved.
This comment was marked as resolved.
@mickgiles it looks like you typed in the wrong confirmation number (the debug logs say it must be six characters long). Double check the info you put in to make sure it is correct. |
This comment was marked as resolved.
This comment was marked as resolved.
It works fine running on bare metal with the same config Logsauto-southwest | 2024-07-02 02:38:06 DEBUG Process-1[webdriver:177]: Waiting for trips_request_id to be set |
This comment was marked as resolved.
This comment was marked as resolved.
|
So as of right now is the login functionality not supposed to work at all? |
No, it’s supposed to and has been working for me. Not sure at the moment why you are having issues. |
Do you have any special characters in your account password? If so, try removing them first. |
|
I'm trying to run this against two reservations. One works, the other consistently yields this. Latest UPDATE: the login method DOES seem to work for the broken one. Reservation one: login works, confirmation doesn't |
|
@dmytrokoren, do you think adding a random delay before clicking the first link (js_click after open) will help lower login detection errors? I unfortunately can't reproduce this (and not sure if you can either), so I can't test this. If anyone else is running into this issue and wants to try the above suggestion, you can add the following on line 152 of self._take_debug_screenshot(driver, "after_page_load.png")
+ time.sleep(random_sleep_duration(3, 8))
driver.js_click("(//div[@data-qa='placement-link'])[2]") |
Log(southwest-venv) ➜ auto-southwest-check-in git:(develop) ✗ python3 southwest.py --verbose 2024-07-09 20:16:58 DEBUG Process-1[reservation_monitor:58]: Acquiring lock... (Session info: chrome=126.0.6478.127) Stacktrace: 0 uc_driver 0x0000000100d5c0e8 uc_driver + 5169384 1 uc_driver 0x0000000100d53fba uc_driver + 5136314 2 uc_driver 0x00000001008d036c uc_driver + 402284 3 uc_driver 0x00000001009246b6 uc_driver + 747190 4 uc_driver 0x00000001009224e8 uc_driver + 738536 5 uc_driver 0x000000010091fef7 uc_driver + 728823 6 uc_driver 0x000000010091ed12 uc_driver + 724242 7 uc_driver 0x0000000100912562 uc_driver + 673122 8 uc_driver 0x0000000100940ab2 uc_driver + 862898 9 uc_driver 0x0000000100911ed8 uc_driver + 671448 10 uc_driver 0x0000000100940c6e uc_driver + 863342 11 uc_driver 0x000000010095ff57 uc_driver + 991063 12 uc_driver 0x0000000100940853 uc_driver + 862291 13 uc_driver 0x00000001009105c6 uc_driver + 665030 14 uc_driver 0x0000000100910e4e uc_driver + 667214 15 uc_driver 0x0000000100d1ed00 uc_driver + 4918528 16 uc_driver 0x0000000100d23cfd uc_driver + 4939005 17 uc_driver 0x0000000100d243d5 uc_driver + 4940757 18 uc_driver 0x0000000100cffde4 uc_driver + 4791780 19 uc_driver 0x0000000100d246c9 uc_driver + 4941513 20 uc_driver 0x0000000100cf15b4 uc_driver + 4732340 21 uc_driver 0x0000000100d44898 uc_driver + 5073048 22 uc_driver 0x0000000100d44a57 uc_driver + 5073495 23 uc_driver 0x0000000100d53b6e uc_driver + 5135214 24 libsystem_pthread.dylib 0x00007ff80745818b _pthread_start + 99 25 libsystem_pthread.dylib 0x00007ff807453ae3 thread_start + 15 |
|
Anyone try this image, see if it helps: docker pull dmytrokoren/auto-southwest-check-in:develop |
|
Still getting a |
It most likely due to your IP address. I had the same issue, I turned off my VPN and it started working. (this applied to running locally or docker). |
|
I just had a successful check in - Position A39
|
Have you had any successful logins? I haven't been able to login successfully for the past 10 commits on develop. |
|
@jdholtz - develop branch works great for me on the initial run... lets see how it goes with intervals for fare check. ill update |
|
I changed my config to check once every 24 hours...it worked for 3 days and then failed yesterday with 403s on every check. I just restarted it and it's again failing every time (Windows/Docker). |
Are these using the latest develop changes/image? There was a recent PR that was merged that should help avoid 403/429s. |
I have been using the latest version of dmytrokoren/alpha-legacy-windock. |
|
@dmytrokoren - I've been using the latest version of dmytrokoren/auto-southwest-check-in:alpha-legacy-windock and I'm getting this error when trying to look for check in banner: 2024-10-10 03:40:37 ERROR Process-1[webdriver:186]: WebDriver initialization failed: Message: Process Process-1: |
|
Try again either one of docker images.. |
|
using alpha-legacy-windock I get the following error. but I don't get it consistently, only occasionally |
|
@dmytrokoren wasn't clear to me in the thread -- is your fork further along/working more consistently than jdholtz's develop branch? |
|
@dmytrokoren looks like the 429 errors are rearing itself again. That or the timing while waiting for headers. Let me know if there's anything you'd like me to try on my end. I find it interesting though that when I checked to see if their flights got checked in it appeared to have checked in just fine? Or could be coincidence, who knows. I should add that several hours before the flight checkin, everything regarding farechecks was working correctly, up until check-in time. And since then, all has failed, so I wonder if something occurred today? |
|
alpha-legacy-windock had been working for me for awhile. Then it started working only on the initial check; every subsequent 24 hour check failed. Now it fails even on the initial check: "Timeout while refreshing headers. Skipping reservation retrieval" |
The fix in #313 fixed this issue for me. |
|
@sevenlayercookie thanks I just saw that fix as well. It definitely works I updated my fork to implement it. |
|
Updated: dmytrokoren/auto-southwest-check-in:develop as from previous issue headers_urls has been changes in this image and user_agent has been removed. |
|
I am still getting the 429 error, even with latest develop branch. @dmytrokoren I tried your docker images, and they are showing the same issues with the 429. This is on Windows via Docker. When I run this on Linux (Fedora 41), things are working fine. Could the docker images need some work? |
|
I had the 400 on first attempt by the script... |
This means that the check-in attempt was too early (as it went through in later attempts). I’ve almost always seen this happen on the first attempt as the time isn’t exactly synchronized between the Southwest servers and NTP servers. It would be a good experiment to try checking in a second or two after the minute to see if we can avoid this first attempt failure. This may then speed up the check-in as it takes ~4 seconds for the first attempt to report a failure before the script tries again. |
I will try adding a second... |
|
FYI, When trying to use latest develop with username/password I am seeing the 429. Using just confirmation number doesn't have any issues. |
Since it seems unrelated issue, I created separate issue for the 400 at check-in and copied context there. |
I'm seeing the same behavior as well. I'll look into this. |
|
I don't have that issue in my repo dev branch. |
|
Confirmation Numbers working for me as well. |
|
Sorry if not helpful, might the solution shown here help overcome these errors: https://youtu.be/ji8F8ppY8bs?t=580 (Around 9:40 to 11:20) I realize he's using requests in python as opposed to opening a headless browser, but perhaps whatever the curl cffi project is using to circumvent the issue can be replicated? |
@dmytrokoren what branch is that called? Is it the most recently updated one,
That looks promising. I'll definitely look into this. Thanks a lot @Royal2000H! |
|
I'm receiving the DIV not clickable error. Not using Docker. I believe this is related to other issues listed in this thread? 2025-01-09 20:20:49 DEBUG MainProcess[log:24]: Initialized the application 2025-01-09 20:20:49 DEBUG Process-1[reservation_monitor:65]: Acquiring lock... ... is not clickable at point (712, 836). Other element would receive the click: ... (Session info: chrome=131.0.6778.264) Stacktrace: #0 0x5f9e9cf0e1fa #1 0x5f9e9ca1e810 #2 0x5f9e9ca74206 #3 0x5f9e9ca7216d #4 0x5f9e9ca6f885 #5 0x5f9e9ca6ea48 #6 0x5f9e9ca621f5 #7 0x5f9e9ca91582 #8 0x5f9e9ca61b38 #9 0x5f9e9ca9174e #10 0x5f9e9cab0007 #11 0x5f9e9ca91323 #12 0x5f9e9ca5fde0 #13 0x5f9e9ca60dbe #14 0x5f9e9ceda12b #15 0x5f9e9cede0c7 #16 0x5f9e9cec76cc #17 0x5f9e9cedec47 #18 0x5f9e9ceac67f #19 0x5f9e9cefd288 #20 0x5f9e9cefd450 #21 0x5f9e9cf0d076 #22 0x79163e294ac3 |
|
403 Errors when using reservation numbers since upgrading to 8.2. Eventually fails and quits after 20 attempts. |
|
Same issue here. Seems working after I set TZ to the location that corresponds to my IP address. The default TZ is UTC I believe. I am not sure is it related. In Docker environment. Would it be possible to use something like undetected-chromedriver? Log Here |
|
i upgraded to 8.2 and my latest check-in failed with a 403. downgraded to 8.1 worked fine. was able to reproduce by upgrading/downgrading a second time (8.2 failed again, 8.1 succeeded). between switching versions, i did a View error log |
and others
Version
v7.5 (develop branch)
Browser Version
N/A
Description
With the merge of #274 on the
developbranch, 403 and 429 errors are being handled much better (or not even seen). I want to consolidate the #201 and #230 threads into one. Using the thread below, people can report if they are or aren't seeing these errors as well as the environment they're using (Docker, laptop, server, etc.) and how many accounts/reservations are being monitored.To Reproduce
--verboseflag or the log files which will have more information on any failed attempts)Expected Behavior
It is not expected that you never see 403 or 429 errors again. However, with the recent changes you should still eventually have successful attempts at logging in, scheduling check ins, fare checking, and checking in. The goal is to have no attempts too many times to the point they are not retried (the corresponding log message:
Failed to make request after ... attempts: ...)Relevant logs and program output
No response
Additional context
For the most part, only logs like the following are helpful.
Request error on attempt ... Sleeping for 1.98 seconds until next attemptPasting all logs are fine, but please use a collapsed section in order to not clutter the main thread.
To get the latest changes, you can either use Docker or the
developbranch locally.Docker:
docker pull jdholtz/auto-southwest-check-in:developLocal:
git pull && git checkout developThe text was updated successfully, but these errors were encountered: