Element {(//div[@data-qa='placement-link'])[2]} was not present after 7 seconds

[henryjj99]

Version

v8.0

Browser Version

118.0.5993.88

Description

Not sure whats causing this issue. Debug info is as follows:

selenium.common.exceptions.ElementClickInterceptedException: Message: element click intercepted: Element <div data-qa="placement-link">...</div> is not clickable at point (195, 137). Other element would receive the click: <div class="backdrop visible active"></div>
  (Session info: chrome=118.0.5993.88)

seleniumbase.common.exceptions.NoSuchElementException: Message: 
 Element {(//div[@data-qa='placement-link'])[2]} was not present after 7 seconds!

Restarting and rerunning Python script would make this error go away

But when you realized you had this issue and tried to check in manually, it might already be too late yall know.

Is it because Southwest changes their check-in page sometimes?

To Reproduce

Running Python directly. Cannot reproduce stably. Error only occurs occasionally.

Expected Behavior

No response

Relevant logs and program output

No response

Additional context

No response

[dmytrokoren]

@henryjj99 - try this repo/branch:

https://github.com/dmytrokoren/auto-southwest-check-in/tree/modified_webdriver_and_updated_requirements

[jdholtz]

Is it because Southwest changes their check-in page sometimes?

No, Southwest’s page has stayed consistent. Usually, I’ve seen this error occur either because it detects you’re a bot or your network takes too long to load the page.

Do you have a slower network connection that could cause a page take a long time to load? I’ve seen this occasionally on my Raspberry Pi.

dmytrokoren has been working a lot on the detection part. Definitely try out his image to see if it’s more stable for you.

[henryjj99]

Is it because Southwest changes their check-in page sometimes?

No, Southwest’s page has stayed consistent. Usually, I’ve seen this error occur either because it detects you’re a bot or your network takes too long to load the page.

Do you have a slower network connection that could cause a page take a long time to load? I’ve seen this occasionally on my Raspberry Pi.

dmytrokoren has been working a lot on the detection part. Definitely try out his image to see if it’s more stable for you.

Will give it a try and report back!

I use Ethernet so it shouldn't be a network issue. So I suspect it might be bot detection.

[jselleck-sans]

This started for me this week as well. I've never had this error till this week.

raise exception_class(message, screen, stacktrace) selenium.common.exceptions.ElementClickInterceptedException: Message: element click intercepted: Element <div data-qa="placement-link">...</div> is not clickable at point (195, 193). Other element would receive the click: <div class="popup-head">...</div> (Session info: chrome=128.0.6613.120)

[dmytrokoren]

@henryjj99 @jselleck-sans - give it a try (new enhancements):

Docker: docker pull dmytrokoren/auto-southwest-check-in:alpha-legacy

Git: git clone -b modified_webdriver_and_updated_requirements https://github.com/dmytrokoren/auto-southwest-check-in.git && cd auto-southwest-check-in

[aaron-pham]

Adding a loop here might be a good idea.. if the exception is thrown.. try again? I just had a check in fail due to this.

Will give @dmytrokoren fork a try!

[dmytrokoren]

Give this image a try:

Docker: docker pull dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

[aaron-pham]

@dmytrokoren

might be something with my network/isp, but it seems like docker always gives a 403 for the fare check portion. I actually always run this script "raw" on my pc. docker hasn't worked. do you have any ideas? I am on windows.

[dmytrokoren]

@dmytrokoren

might be something with my network/isp, but it seems like docker always gives a 403 for the fare check portion. I actually always run this script "raw" on my pc. docker hasn't worked. do you have any ideas? I am on windows.

Very possible...

Give this a try, new changes made:

Docker: docker pull dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

[jdholtz]

might be something with my network/isp

If running it without Docker on the same machine works, I doubt it would be detected at the network level. More likely that it is fingerprinting something in Docker, but we aren’t sure what that is yet…

[aaron-pham]

@dmytrokoren might be something with my network/isp, but it seems like docker always gives a 403 for the fare check portion. I actually always run this script "raw" on my pc. docker hasn't worked. do you have any ideas? I am on windows.

Very possible...

Give this a try, new changes made:

Docker: docker pull dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

What is the difference on this image and building the docker image from your branch modified_webdriver_and_updated_requirements ? That image actually seems to work, but when I build the image manually off that branch, it does not work. Or is it due to changes you have not pushed yet?

[dmytrokoren]

@dmytrokoren

might be something with my network/isp, but it seems like docker always gives a 403 for the fare check portion. I actually always run this script "raw" on my pc. docker hasn't worked. do you have any ideas? I am on windows.

Very possible...

Give this a try, new changes made:

Docker: docker pull dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

What is the difference on this image and building the docker image from your branch modified_webdriver_and_updated_requirements ? That image actually seems to work, but when I build the image manually off that branch, it does not work. Or is it due to changes you have not pushed yet?

I didn't push changes yet.

[aaron-pham]

@jdholtz

Thoughts on catching this exception Element {(//div[@data-qa='placement-link'])[2]} was not present after 7 seconds! and trying again? I added a simple while loop to test & it seems like if it fails, it typically will work on the next try.

[dmytrokoren]

@jdholtz

Thoughts on catching this exception Element {(//div[@data-qa='placement-link'])[2]} was not present after 7 seconds!

and trying again? I added a simple while loop to test & it seems like if it fails, it typically will work on the next try.

@aaron-pham does js_click work for you?

[aaron-pham]

@jdholtz Thoughts on catching this exception Element {(//div[@data-qa='placement-link'])[2]} was not present after 7 seconds! and trying again? I added a simple while loop to test & it seems like if it fails, it typically will work on the next try.

@aaron-pham does js_click work for you?

It fails less, but it still fails occasionally. Maybe like 10% failure rate? On my local code I had the timeout to 15 seconds too and it sometimes still times out. I am thinking its SW detecting us. My network is typically very stable. I had two check-ins and one failed due to this exception.

[jdholtz]

Thoughts on catching this exception Element {(//div[@data-qa='placement-link'])[2]} was not present after 7 seconds! and trying again?

We could do that. I would think setting the timeout to 20ish seconds would provide the same functionality, but you said it is still failing occasionally with a 15s timeout.

As @dmytrokoren has in #283, it might be better to just go straight to the check-in page instead of going to the home page and clicking the button (depending on if it leads to more detections or not though).

[aaron-pham]

We could do that. I would think setting the timeout to 20ish seconds would provide the same functionality, but you said it is still failing occasionally with a 15s timeout.

I'm thinking it's SW doing some detection and that page might never pop up. It's odd to me that it would take 15+ seconds. Even 7 is pretty long. I'll play around w/30s + timeout and see if I still run into the issue.

[luisiam]

Tried dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

I am monitoring 4 accounts. 1 out of the 4 accounts successfully scheduled check-in. Previously, the docker image just error out and stopped.

[dmytrokoren]

Thoughts on catching this exception Element {(//div[@data-qa='placement-link'])[2]} was not present after 7 seconds!

and trying again?

We could do that. I would think setting the timeout to 20ish seconds would provide the same functionality, but you said it is still failing occasionally with a 15s timeout.

As @dmytrokoren has in #283, it might be better to just go straight to the check-in page instead of going to the home page and clicking the button (depending on if it leads to more detections or not though).

I have noticed that going directly to the check-in page throws error 403 on retrieving reservation and flight matches (sometimes successful on 3-4 attempt). So the best bet is to start from home page and navigate to check-in.

I'm testing right now with uc_open and uc_click... looks promising I'll make an image soon and commit the code to test for everyone.

[him229]

Some additional context if it helps @dmytrokoren -- tried dmytrokoren/auto-southwest-check-in:alpha-legacy-windock just now and ran into this error:

seleniumbase.common.exceptions.NoSuchElementException: Message: 
 Element {//*[@alt='Check in banner']} was not present after 10 seconds!

EDIT: also tried :beta -- same error

[dmytrokoren]

dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

@him229 @luisiam @aaron-pham made new changes, try again: dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

[luisiam]

dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

@him229 @luisiam @aaron-pham made new changes, try again: dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

I am getting Timeout waiting for the 'heaters_set' attribute

[dmytrokoren]

dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

@him229 @luisiam @aaron-pham made new changes, try again: dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

I am getting Timeout waiting for the 'heaters_set' attribute

Rerun it once, this can happen.. I just had second successful run after 4 hr interval. Share full log. And what hardware you running on.

[luisiam]

dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

@him229 @luisiam @aaron-pham made new changes, try again: dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

I am getting Timeout waiting for the 'heaters_set' attribute

Rerun it once, this can happen.. I just had second successful run after 4 hr interval. Share full log. And what hardware you running on.

Rerun and it's the same. I am running the docker image on a proxmox LXC.

2024-09-17 17:34:26 DEBUG MainProcess[config:122]: Using 1 notification services

2024-09-17 17:34:26 DEBUG MainProcess[config:144]: Creating configurations for 4 accounts

2024-09-17 17:34:26 DEBUG MainProcess[config:60]: Setting check fares to False

2024-09-17 17:34:26 DEBUG MainProcess[config:60]: Setting check fares to False

2024-09-17 17:34:26 DEBUG MainProcess[config:151]: Creating configurations for 0 reservations

2024-09-17 17:34:26 INFO MainProcess[main:97]: Monitoring 4 accounts and 0 reservations

2024-09-17 17:34:26 DEBUG Process-1[reservation_monitor:58]: Acquiring lock...

2024-09-17 17:34:26 DEBUG Process-1[reservation_monitor:60]: Lock acquired

2024-09-17 17:34:26 DEBUG Process-1[reservation_monitor:199]: Retrieving reservations for account

2024-09-17 17:34:26 DEBUG Process-4[reservation_monitor:58]: Acquiring lock...

2024-09-17 17:34:26 DEBUG Process-2[reservation_monitor:58]: Acquiring lock...

2024-09-17 17:34:26 DEBUG Process-1[webdriver:389]: Started virtual display successfully

2024-09-17 17:34:26 DEBUG Process-1[webdriver:156]: Starting webdriver for current session

2024-09-17 17:34:26 DEBUG Process-1[webdriver:170]: Using browser version: 124.0.6367.78

2024-09-17 17:34:26 DEBUG Process-1[webdriver:196]: Retrieving new headers

2024-09-17 17:34:26 DEBUG Process-1[webdriver:176]: Loading Southwest check-in page (this may take a moment)

2024-09-17 17:34:27 DEBUG Process-3[reservation_monitor:58]: Acquiring lock...

2024-09-17 17:34:37 DEBUG Process-1[webdriver:112]: Logging into account to get a list of reservations and valid headers

2024-09-17 17:34:41 DEBUG Process-1[webdriver:237]: Waiting for headers_set to be set (timeout: 180 seconds)

2024-09-17 17:34:42 DEBUG Process-1[webdriver:229]: Login response has been received

2024-09-17 17:34:43 DEBUG Process-1[webdriver:233]: Upcoming trips response has been received

2024-09-17 17:37:41 DEBUG Process-1[webdriver:248]: Timeout waiting for the 'headers_set' attribute

2024-09-17 17:37:41 DEBUG Process-1[reservation_monitor:214]: Timeout while retrieving reservations during login. Retrying

Notice: Webdriver time out during account retrieval for xxxxx. Skipping reservation retrieval until next interval

2024-09-17 17:37:41 DEBUG Process-1[webdriver:389]: Started virtual display successfully

2024-09-17 17:37:41 DEBUG Process-1[webdriver:156]: Starting webdriver for current session

2024-09-17 17:37:41 DEBUG Process-1[webdriver:170]: Using browser version: 124.0.6367.78

2024-09-17 17:37:41 DEBUG Process-1[webdriver:196]: Retrieving new headers

2024-09-17 17:37:41 DEBUG Process-1[webdriver:176]: Loading Southwest check-in page (this may take a moment)

2024-09-17 17:37:51 DEBUG Process-1[webdriver:112]: Logging into account to get a list of reservations and valid headers

2024-09-17 17:37:55 DEBUG Process-1[webdriver:237]: Waiting for headers_set to be set (timeout: 180 seconds)

2024-09-17 17:37:57 DEBUG Process-1[webdriver:229]: Login response has been received

2024-09-17 17:37:58 DEBUG Process-1[webdriver:233]: Upcoming trips response has been received

[dmytrokoren]

dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

@him229 @luisiam @aaron-pham made new changes, try again: dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

I am getting Timeout waiting for the 'heaters_set' attribute

Rerun it once, this can happen.. I just had second successful run after 4 hr interval. Share full log. And what hardware you running on.

Rerun and it's the same. I am running the docker image on a proxmox LXC.

2024-09-17 17:34:26 DEBUG MainProcess[config:122]: Using 1 notification services

2024-09-17 17:34:26 DEBUG MainProcess[config:144]: Creating configurations for 4 accounts

2024-09-17 17:34:26 DEBUG MainProcess[config:60]: Setting check fares to False

2024-09-17 17:34:26 DEBUG MainProcess[config:60]: Setting check fares to False

2024-09-17 17:34:26 DEBUG MainProcess[config:151]: Creating configurations for 0 reservations

2024-09-17 17:34:26 INFO MainProcess[main:97]: Monitoring 4 accounts and 0 reservations

2024-09-17 17:34:26 DEBUG Process-1[reservation_monitor:58]: Acquiring lock...

2024-09-17 17:34:26 DEBUG Process-1[reservation_monitor:60]: Lock acquired

2024-09-17 17:34:26 DEBUG Process-1[reservation_monitor:199]: Retrieving reservations for account

2024-09-17 17:34:26 DEBUG Process-4[reservation_monitor:58]: Acquiring lock...

2024-09-17 17:34:26 DEBUG Process-2[reservation_monitor:58]: Acquiring lock...

2024-09-17 17:34:26 DEBUG Process-1[webdriver:389]: Started virtual display successfully

2024-09-17 17:34:26 DEBUG Process-1[webdriver:156]: Starting webdriver for current session

2024-09-17 17:34:26 DEBUG Process-1[webdriver:170]: Using browser version: 124.0.6367.78

2024-09-17 17:34:26 DEBUG Process-1[webdriver:196]: Retrieving new headers

2024-09-17 17:34:26 DEBUG Process-1[webdriver:176]: Loading Southwest check-in page (this may take a moment)

2024-09-17 17:34:27 DEBUG Process-3[reservation_monitor:58]: Acquiring lock...

2024-09-17 17:34:37 DEBUG Process-1[webdriver:112]: Logging into account to get a list of reservations and valid headers

2024-09-17 17:34:41 DEBUG Process-1[webdriver:237]: Waiting for headers_set to be set (timeout: 180 seconds)

2024-09-17 17:34:42 DEBUG Process-1[webdriver:229]: Login response has been received

2024-09-17 17:34:43 DEBUG Process-1[webdriver:233]: Upcoming trips response has been received

2024-09-17 17:37:41 DEBUG Process-1[webdriver:248]: Timeout waiting for the 'headers_set' attribute

2024-09-17 17:37:41 DEBUG Process-1[reservation_monitor:214]: Timeout while retrieving reservations during login. Retrying

Notice: Webdriver time out during account retrieval for xxxxx. Skipping reservation retrieval until next interval

2024-09-17 17:37:41 DEBUG Process-1[webdriver:389]: Started virtual display successfully

2024-09-17 17:37:41 DEBUG Process-1[webdriver:156]: Starting webdriver for current session

2024-09-17 17:37:41 DEBUG Process-1[webdriver:170]: Using browser version: 124.0.6367.78

2024-09-17 17:37:41 DEBUG Process-1[webdriver:196]: Retrieving new headers

2024-09-17 17:37:41 DEBUG Process-1[webdriver:176]: Loading Southwest check-in page (this may take a moment)

2024-09-17 17:37:51 DEBUG Process-1[webdriver:112]: Logging into account to get a list of reservations and valid headers

2024-09-17 17:37:55 DEBUG Process-1[webdriver:237]: Waiting for headers_set to be set (timeout: 180 seconds)

2024-09-17 17:37:57 DEBUG Process-1[webdriver:229]: Login response has been received

2024-09-17 17:37:58 DEBUG Process-1[webdriver:233]: Upcoming trips response has been received

Thanks for the logs. I think cdp listener is not capturing anything. If you can try docker windows or Mac. It should also work for Synology containers. I'm thinking proxmox docker something is being flagged..

[luisiam]

dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

@him229 @luisiam @aaron-pham made new changes, try again: dmytrokoren/auto-southwest-check-in:alpha-legacy-windock

I am getting Timeout waiting for the 'heaters_set' attribute

Rerun it once, this can happen.. I just had second successful run after 4 hr interval. Share full log. And what hardware you running on.

Rerun and it's the same. I am running the docker image on a proxmox LXC.

2024-09-17 17:34:26 DEBUG MainProcess[config:122]: Using 1 notification services

2024-09-17 17:34:26 DEBUG MainProcess[config:144]: Creating configurations for 4 accounts

2024-09-17 17:34:26 DEBUG MainProcess[config:60]: Setting check fares to False

2024-09-17 17:34:26 DEBUG MainProcess[config:60]: Setting check fares to False

2024-09-17 17:34:26 DEBUG MainProcess[config:151]: Creating configurations for 0 reservations

2024-09-17 17:34:26 INFO MainProcess[main:97]: Monitoring 4 accounts and 0 reservations

2024-09-17 17:34:26 DEBUG Process-1[reservation_monitor:58]: Acquiring lock...

2024-09-17 17:34:26 DEBUG Process-1[reservation_monitor:60]: Lock acquired

2024-09-17 17:34:26 DEBUG Process-1[reservation_monitor:199]: Retrieving reservations for account

2024-09-17 17:34:26 DEBUG Process-4[reservation_monitor:58]: Acquiring lock...

2024-09-17 17:34:26 DEBUG Process-2[reservation_monitor:58]: Acquiring lock...

2024-09-17 17:34:26 DEBUG Process-1[webdriver:389]: Started virtual display successfully

2024-09-17 17:34:26 DEBUG Process-1[webdriver:156]: Starting webdriver for current session

2024-09-17 17:34:26 DEBUG Process-1[webdriver:170]: Using browser version: 124.0.6367.78

2024-09-17 17:34:26 DEBUG Process-1[webdriver:196]: Retrieving new headers

2024-09-17 17:34:26 DEBUG Process-1[webdriver:176]: Loading Southwest check-in page (this may take a moment)

2024-09-17 17:34:27 DEBUG Process-3[reservation_monitor:58]: Acquiring lock...

2024-09-17 17:34:37 DEBUG Process-1[webdriver:112]: Logging into account to get a list of reservations and valid headers

2024-09-17 17:34:41 DEBUG Process-1[webdriver:237]: Waiting for headers_set to be set (timeout: 180 seconds)

2024-09-17 17:34:42 DEBUG Process-1[webdriver:229]: Login response has been received

2024-09-17 17:34:43 DEBUG Process-1[webdriver:233]: Upcoming trips response has been received

2024-09-17 17:37:41 DEBUG Process-1[webdriver:248]: Timeout waiting for the 'headers_set' attribute

2024-09-17 17:37:41 DEBUG Process-1[reservation_monitor:214]: Timeout while retrieving reservations during login. Retrying

Notice: Webdriver time out during account retrieval for xxxxx. Skipping reservation retrieval until next interval

2024-09-17 17:37:41 DEBUG Process-1[webdriver:389]: Started virtual display successfully

2024-09-17 17:37:41 DEBUG Process-1[webdriver:156]: Starting webdriver for current session

2024-09-17 17:37:41 DEBUG Process-1[webdriver:170]: Using browser version: 124.0.6367.78

2024-09-17 17:37:41 DEBUG Process-1[webdriver:196]: Retrieving new headers

2024-09-17 17:37:41 DEBUG Process-1[webdriver:176]: Loading Southwest check-in page (this may take a moment)

2024-09-17 17:37:51 DEBUG Process-1[webdriver:112]: Logging into account to get a list of reservations and valid headers

2024-09-17 17:37:55 DEBUG Process-1[webdriver:237]: Waiting for headers_set to be set (timeout: 180 seconds)

2024-09-17 17:37:57 DEBUG Process-1[webdriver:229]: Login response has been received

2024-09-17 17:37:58 DEBUG Process-1[webdriver:233]: Upcoming trips response has been received

Thanks for the logs. I think cdp listener is not capturing anything. If you can try docker windows or Mac. It should also work for Synology containers. I'm thinking proxmox docker something is being flagged..

Actually 2 out of 4 accounts successfully scheduled the check-in after I waited long enough. I am installing docker on a Debian LXC under proxmox. Shouldn't it be equivalent to linux docker?

Slightly different error for another account

2024-09-17 17:40:55 DEBUG Process-4[reservation_monitor:60]: Lock acquired

2024-09-17 17:40:55 DEBUG Process-4[reservation_monitor:199]: Retrieving reservations for account

2024-09-17 17:40:55 DEBUG Process-1[reservation_monitor:144]: Sleeping for 86010 seconds

2024-09-17 17:40:55 DEBUG Process-4[webdriver:389]: Started virtual display successfully

2024-09-17 17:40:55 DEBUG Process-4[webdriver:156]: Starting webdriver for current session

2024-09-17 17:40:56 DEBUG Process-4[webdriver:170]: Using browser version: 124.0.6367.78

2024-09-17 17:40:56 DEBUG Process-4[webdriver:196]: Retrieving new headers

2024-09-17 17:40:56 DEBUG Process-4[webdriver:176]: Loading Southwest check-in page (this may take a moment)

2024-09-17 17:41:06 DEBUG Process-4[webdriver:112]: Logging into account to get a list of reservations and valid headers

2024-09-17 17:41:08 DEBUG Process-4[webdriver:237]: Waiting for headers_set to be set (timeout: 180 seconds)

2024-09-17 17:41:08 DEBUG Process-4[webdriver:251]: headers_set set successfully

2024-09-17 17:41:08 DEBUG Process-4[webdriver:237]: Waiting for login_request_id to be set (timeout: 180 seconds)

2024-09-17 17:41:10 DEBUG Process-4[webdriver:229]: Login response has been received

2024-09-17 17:41:10 DEBUG Process-4[webdriver:251]: login_request_id set successfully

2024-09-17 17:41:10 DEBUG Process-4[webdriver:398]: Stopped virtual display successfully

2024-09-17 17:41:10 DEBUG Process-4[webdriver:309]: Logging in failed for an unknown reason

2024-09-17 17:41:10 DEBUG Process-4[reservation_monitor:219]: Encountered a Too Many Requests error while logging in. Retrying

2024-09-17 17:41:10 DEBUG Process-4[webdriver:389]: Started virtual display successfully

2024-09-17 17:41:10 DEBUG Process-4[webdriver:156]: Starting webdriver for current session

2024-09-17 17:41:10 DEBUG Process-4[webdriver:170]: Using browser version: 124.0.6367.78

2024-09-17 17:41:10 DEBUG Process-4[webdriver:196]: Retrieving new headers

2024-09-17 17:41:10 DEBUG Process-4[webdriver:176]: Loading Southwest check-in page (this may take a moment)

2024-09-17 17:41:21 DEBUG Process-4[webdriver:112]: Logging into account to get a list of reservations and valid headers

2024-09-17 17:41:23 DEBUG Process-4[webdriver:237]: Waiting for headers_set to be set (timeout: 180 seconds)

2024-09-17 17:41:23 DEBUG Process-4[webdriver:251]: headers_set set successfully

2024-09-17 17:41:24 DEBUG Process-4[webdriver:237]: Waiting for login_request_id to be set (timeout: 180 seconds)

2024-09-17 17:41:24 DEBUG Process-4[webdriver:229]: Login response has been received

2024-09-17 17:41:24 DEBUG Process-4[webdriver:251]: login_request_id set successfully

2024-09-17 17:41:24 DEBUG Process-4[webdriver:398]: Stopped virtual display successfully

2024-09-17 17:41:24 DEBUG Process-4[webdriver:309]: Logging in failed for an unknown reason

2024-09-17 17:41:24 DEBUG Process-4[reservation_monitor:219]: Encountered a Too Many Requests error while logging in. Retrying

2024-09-17 17:41:24 DEBUG Process-4[reservation_monitor:226]: Too Many Requests error persists. Skipping reservation retrieval

Notice: Encountered a Too Many Requests error while logging in for xxxxx. Skipping reservation retrieval until next interval```

[dmytrokoren]

Technically yes but we don't know why in some docker containers successful like mine but others get login issue or fare check issues. It's definitely something inside container that is triggering. That's just my opinion...

[luisiam]

Technically yes but we don't know why in some docker containers successful like mine but others get login issue or fare check issues. It's definitely something inside container that is triggering. That's just my opinion...

But some accounts logged in successfully. If it has something to do with docker on LXC, all account login will fail, right?

[dmytrokoren]

Technically yes but we don't know why in some docker containers successful like mine but others get login issue or fare check issues. It's definitely something inside container that is triggering. That's just my opinion...

But some accounts logged in successfully. If it has something to do with docker on LXC, all account login will fail, right?

Sometimes SW will detect and sometimes it won't.. the accounts logged in was probably new headers fetched successfully and logged you in and then use that cached headers for another account to login successfully. But then when using cached headers again for 3rd account it failed because SW expired or invalidated the cached headers and login failed... it's one crazy flow but SW is not playing nice...

[luisiam]

The cadence is

1. Fail
2. Fail
3. Success
4. Success

The 1st and 2nd trial should be using new headers (assuming nothing is cached when the container first started) but they failed.

Will using confirmation number have a higher rate of success than using account login?

[dmytrokoren]

The cadence is

1. Fail

2. Fail

3. Success

4. Success

The 1st and 2nd trial should be using new headers (assuming nothing is cached when the container first started) but they failed.

Will using confirmation number have a higher rate of success than using account login?

Yes confirmation number will have 90% success if not higher

[luisiam]

The cadence is

1. Fail
2. Fail
3. Success
4. Success

The 1st and 2nd trial should be using new headers (assuming nothing is cached when the container first started) but they failed. Will using confirmation number have a higher rate of success than using account login?

Yes confirmation number will have 90% success if not higher

If I have multiple passengers under the same confirmation number, do I just need a single entry for that confirmation or I need one entry per passenger in the config?

[dmytrokoren]

I believe it's every passenger should be listed in config.json

[aaron-pham]

I believe it's every passenger should be listed in config.json

@luisiam

If passengers share a confirmation number, only one needs to check in. The rest will be checked in automatically.

[luisiam]

@dmytrokoren I just downloaded your latest update and finally all of my monitored accounts can successfully schedule check-in. Not sure how long it will last lol

[rscheurman]

@dmytrokoren Just tried your mentioned docker image dmytrokoren/auto-southwest-check-in:alpha-legacy-windock and it is working for me as well.

[ramenchef]

Getting 403s for both dmytrokoren/auto-southwest-check-in:alpha-legacy-windock and dmytrokoren/auto-southwest-check-in:develop

tried using account and then reservation

2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG MainProcess[log:24]: Initialized the application
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG MainProcess[main:115]: Auto-Southwest Check-In v8.0
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG MainProcess[main:73]: Called with 0 arguments
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG MainProcess[config:132]: Initializing configuration file
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG MainProcess[config:161]: Reading the configuration file
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG MainProcess[config:174]: Reading configuration from environment variables
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG MainProcess[config:60]: Setting check fares to True
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG MainProcess[config:75]: Setting retrieval interval to 24 hours
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG MainProcess[config:95]: Setting notification 24 hour time to True
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG MainProcess[config:109]: Setting notification level to <NotificationLevel.NOTICE: 1>
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG MainProcess[config:122]: Using 1 notification services
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG MainProcess[config:151]: Creating configurations for 1 reservations
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG MainProcess[config:71]: A Healthchecks URL has been provided
2024-10-10 19:33:28 2024-10-11 02:33:28 INFO MainProcess[main:99]: Monitoring 0 accounts and 1 reservation
2024-10-10 19:33:28 
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG Process-1[reservation_monitor:68]: Acquiring lock...
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG Process-1[reservation_monitor:70]: Lock acquired
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG Process-1[checkin_scheduler:48]: Refreshing headers for current session
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG Process-1[webdriver:385]: Started virtual display successfully
2024-10-10 19:33:28 2024-10-11 02:33:28 DEBUG Process-1[webdriver:157]: Starting webdriver for current session
2024-10-10 19:33:29 2024-10-11 02:33:29 DEBUG Process-1[webdriver:170]: Using browser version: 112.0.5615.165
2024-10-10 19:33:29 2024-10-11 02:33:29 DEBUG Process-1[webdriver:199]: Retrieving new headers
2024-10-10 19:33:29 2024-10-11 02:33:29 DEBUG Process-1[webdriver:176]: Loading Southwest check-in page (this may take a moment)
2024-10-10 19:33:41 2024-10-11 02:33:41 DEBUG Process-1[webdriver:96]: Waiting for valid headers
2024-10-10 19:33:41 2024-10-11 02:33:41 DEBUG Process-1[webdriver:240]: Waiting for 'headers_set' to be set (timeout: 90 seconds)
2024-10-10 19:33:41 2024-10-11 02:33:41 DEBUG Process-1[webdriver:246]: 'headers_set' set successfully
2024-10-10 19:33:41 2024-10-11 02:33:41 DEBUG Process-1[webdriver:394]: Stopped virtual display successfully
2024-10-10 19:33:41 2024-10-11 02:33:41 DEBUG Process-1[reservation_monitor:110]: Scheduling flight check-ins for 1 reservations
2024-10-10 19:33:41 2024-10-11 02:33:41 DEBUG Process-1[checkin_scheduler:81]: Retrieving reservation information
2024-10-10 19:33:41 2024-10-11 02:33:41 DEBUG Process-1[utils:90]: Request error on attempt 1: Forbidden (403). Sleeping for 1.08 seconds until next attempt
2024-10-10 19:33:42 2024-10-11 02:33:42 DEBUG Process-1[utils:90]: Request error on attempt 2: Forbidden (403). Sleeping for 2.10 seconds until next attempt
2024-10-10 19:33:45 2024-10-11 02:33:45 DEBUG Process-1[utils:90]: Request error on attempt 3: Forbidden (403). Sleeping for 1.15 seconds until next attempt
2024-10-10 19:33:46 2024-10-11 02:33:46 DEBUG Process-1[utils:90]: Request error on attempt 4: Forbidden (403). Sleeping for 1.28 seconds until next attempt
2024-10-10 19:33:47 2024-10-11 02:33:47 DEBUG Process-1[utils:90]: Request error on attempt 5: Forbidden (403). Sleeping for 2.36 seconds until next attempt
2024-10-10 19:33:50 2024-10-11 02:33:50 DEBUG Process-1[utils:90]: Request error on attempt 6: Forbidden (403). Sleeping for 2.07 seconds until next attempt
2024-10-10 19:33:52 2024-10-11 02:33:52 DEBUG Process-1[utils:90]: Request error on attempt 7: Forbidden (403). Sleeping for 1.04 seconds until next attempt
2024-10-10 19:33:54 2024-10-11 02:33:54 DEBUG Process-1[utils:90]: Request error on attempt 8: Forbidden (403). Sleeping for 1.10 seconds until next attempt
2024-10-10 19:33:55 2024-10-11 02:33:55 DEBUG Process-1[utils:90]: Request error on attempt 9: Forbidden (403). Sleeping for 2.63 seconds until next attempt
2024-10-10 19:33:58 2024-10-11 02:33:58 DEBUG Process-1[utils:90]: Request error on attempt 10: Forbidden (403). Sleeping for 2.40 seconds until next attempt
2024-10-10 19:34:00 2024-10-11 02:34:00 DEBUG Process-1[utils:90]: Request error on attempt 11: Forbidden (403). Sleeping for 1.93 seconds until next attempt
2024-10-10 19:34:02 2024-10-11 02:34:02 DEBUG Process-1[utils:90]: Request error on attempt 12: Forbidden (403). Sleeping for 1.13 seconds until next attempt
2024-10-10 19:34:04 2024-10-11 02:34:04 DEBUG Process-1[utils:90]: Request error on attempt 13: Forbidden (403). Sleeping for 1.70 seconds until next attempt
2024-10-10 19:34:06 2024-10-11 02:34:06 DEBUG Process-1[utils:90]: Request error on attempt 14: Forbidden (403). Sleeping for 2.99 seconds until next attempt
2024-10-10 19:34:09 2024-10-11 02:34:09 DEBUG Process-1[utils:90]: Request error on attempt 15: Forbidden (403). Sleeping for 1.37 seconds until next attempt
2024-10-10 19:34:10 2024-10-11 02:34:10 DEBUG Process-1[utils:90]: Request error on attempt 16: Forbidden (403). Sleeping for 1.28 seconds until next attempt
2024-10-10 19:34:12 2024-10-11 02:34:12 DEBUG Process-1[utils:90]: Request error on attempt 17: Forbidden (403). Sleeping for 1.80 seconds until next attempt
2024-10-10 19:34:14 2024-10-11 02:34:14 DEBUG Process-1[utils:90]: Request error on attempt 18: Forbidden (403). Sleeping for 1.16 seconds until next attempt
2024-10-10 19:34:16 2024-10-11 02:34:16 DEBUG Process-1[utils:90]: Request error on attempt 19: Forbidden (403). Sleeping for 2.77 seconds until next attempt
2024-10-10 19:34:19 2024-10-11 02:34:19 DEBUG Process-1[utils:90]: Request error on attempt 20: Forbidden (403). Sleeping for 2.77 seconds until next attempt
2024-10-10 19:34:22 2024-10-11 02:34:22 DEBUG Process-1[utils:96]: Failed to make request after 20 attempts: Forbidden (403)
2024-10-10 19:34:22 2024-10-11 02:34:22 DEBUG Process-1[utils:97]: Response body: {
2024-10-10 19:34:22   "code": 403050700
2024-10-10 19:34:22 }
2024-10-10 19:34:22 2024-10-11 02:34:22 DEBUG Process-1[checkin_scheduler:87]: Failed to retrieve reservation info. Error: Forbidden (403). Exiting
2024-10-10 19:34:22 2024-10-11 02:34:22 DEBUG Process-1[notification_handler:80]: Sending failed reservation retrieval notification...
2024-10-10 19:34:22 Error: Failed to retrieve reservation for <NAME> with confirmation number <CONF NUM>. Reason: Forbidden (403).
2024-10-10 19:34:22 Make sure the reservation information is correct and try again.
2024-10-10 19:34:22 
2024-10-10 19:34:22 2024-10-11 02:34:22 DEBUG Process-1[checkin_scheduler:56]: 0 flights found under current reservation
2024-10-10 19:34:22 2024-10-11 02:34:22 DEBUG Process-1[checkin_scheduler:44]: 0 total flights were found
2024-10-10 19:34:22 2024-10-11 02:34:22 DEBUG Process-1[checkin_scheduler:111]: Updating scheduled flights (0 scheduled, 0 found)
2024-10-10 19:34:22 2024-10-11 02:34:22 DEBUG Process-1[checkin_scheduler:125]: 0 new flights found
2024-10-10 19:34:22 2024-10-11 02:34:22 DEBUG Process-1[checkin_scheduler:131]: Scheduling 0 flights for check-in
2024-10-10 19:34:22 2024-10-11 02:34:22 DEBUG Process-1[checkin_scheduler:143]: 0 flights are currently scheduled. Removing old flights
2024-10-10 19:34:22 2024-10-11 02:34:22 DEBUG Process-1[checkin_scheduler:162]: Successfully removed old flights. 0 flights are now scheduled
2024-10-10 19:34:22 2024-10-11 02:34:22 DEBUG Process-1[reservation_monitor:103]: No more flights are scheduled for check-in. Exiting...
2024-10-10 19:34:22 2024-10-11 02:34:22 DEBUG Process-1[reservation_monitor:74]: Stopping monitoring

this is on Windows Docker WSL2/Ubuntu

[dmytrokoren]

Try again either one, I have pushed the latest to both images

[ramenchef]

Looks good so far for reservations. Will swap to account and test that.

[djre4orm]

Sort of still getting this on both branches. It either hangs at

[uc_driver 109.0.5414.74] is now ready for use!

or bombs out with

Element {(//div[@data-qa='placement-link'])[2]} was not present after 7 seconds

That being said the other branch worked 2-3 weeks ago

[dmytrokoren]

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.