Better avoidance of 403/429

[dmytrokoren]

Modified webdriver and updated requirements

[dmytrokoren]

Do you have a Docker image on your repository for this? I think it’d be good to check that this fixes #279 before merging it.

Yes I have updated :develop tag with these new changes.

[dmytrokoren]

@jdholtz can you run :develop tag and see if it works for you, I have made new touch ups. I'll be making new PR or merge to existing!?

[jdholtz]

@jdholtz can you run :develop tag and see if it works for you, I have made new touch ups. I'll be making new PR or merge to existing!?

Yes, it's working for me. You can add the new changes here. So it looks like the two parameters (including this change and #274) are using incognito and is_mobile when initializing the driver. Were you able to reproduce the 403/429 and the incognito parameter fixed it?

[dmytrokoren]

@jdholtz can you run :develop tag and see if it works for you, I have made new touch ups. I'll be making new PR or merge to existing!?

Yes, it's working for me. You can add the new changes here. So it looks like the two parameters (including this change and #274) are using incognito and is_mobile when initializing the driver. Were you able to reproduce the 403/429 and the incognito parameter fixed it?

Yes, I was running it on Mac docker image and I was getting 403 on first try but then I added incognito and the 403 went away. Might be coincidence but I think it still did the trick.

[dmytrokoren]

@jdholtz can you run :develop tag and see if it works for you, I have made new touch ups. I'll be making new PR or merge to existing!?

Yes, it's working for me. You can add the new changes here. So it looks like the two parameters (including this change and #274) are using incognito and is_mobile when initializing the driver. Were you able to reproduce the 403/429 and the incognito parameter fixed it?

Intermittently I do see 403/429 when running multiple times (while testing). Today in docker I'm running 1 account and its running every 4 hours, I did not see any 429 or 403.

[dmytrokoren]

This PR is related to #279

[puluceno]

any plans to get this merged? 😄

[jdholtz]

any plans to get this merged? 😄

Yes but changes related to 403/429s are still being worked on and discussed in #277 and #279.

[Bubba8291]

@dmytrokoren what is the status on this? I have a check in on Tuesday, and I can use this script and post the logs like last time.

[dmytrokoren]

@dmytrokoren what is the status on this? I have a check in on Tuesday, and I can use this script and post the logs like last time.

It's up to date, with pending PR's. 429 error still coming on login at times. But 403 for me is kind of faded.

[Bubba8291]

@dmytrokoren what is the status on this? I have a check in on Tuesday, and I can use this script and post the logs like last time.

It's up to date, with pending PR's. 429 error still coming on login at times. But 403 for me is kind of faded.

Wait is the issues just for login? I've always used this script by configuring it for reservations, not accounts.

[dmytrokoren]

@dmytrokoren what is the status on this? I have a check in on Tuesday, and I can use this script and post the logs like last time.

It's up to date, with pending PR's. 429 error still coming on login at times. But 403 for me is kind of faded.

Wait is the issues just for login? I've always used this script by configuring it for reservations, not accounts.

For me it was mostly login now. If you use reservations you should be fine, most likely will get seats lower B's depends where you flying. When I did checking from Dallas to NYC I got B15... from NyC to Dallas I got A35, which was awesome

[Bubba8291]

@dmytrokoren what is the status on this? I have a check in on Tuesday, and I can use this script and post the logs like last time.

It's up to date, with pending PR's. 429 error still coming on login at times. But 403 for me is kind of faded.

Wait is the issues just for login? I've always used this script by configuring it for reservations, not accounts.

For me it was mostly login now. If you use reservations you should be fine, most likely will get seats lower B's depends where you flying. When I did checking from Dallas to NYC I got B15 which was awesome but from NyC to Dallas I got A35

So you're saying using the account method gives you a better chance at getting a better boarding position? If so, why is that?

[dmytrokoren]

@dmytrokoren what is the status on this? I have a check in on Tuesday, and I can use this script and post the logs like last time.

It's up to date, with pending PR's. 429 error still coming on login at times. But 403 for me is kind of faded.

Wait is the issues just for login? I've always used this script by configuring it for reservations, not accounts.

For me it was mostly login now. If you use reservations you should be fine, most likely will get seats lower B's depends where you flying. When I did checking from Dallas to NYC I got B15 which was awesome but from NyC to Dallas I got A35

So you're saying using the account method gives you a better chance at getting a better boarding position? If so, why is that?

No reservation and login makes no difference. I was just stating the fact that there is still good possibility to get good seats using this script :) depending where you flying to

[Bubba8291]

@dmytrokoren what is the status on this? I have a check in on Tuesday, and I can use this script and post the logs like last time.

It's up to date, with pending PR's. 429 error still coming on login at times. But 403 for me is kind of faded.

Wait is the issues just for login? I've always used this script by configuring it for reservations, not accounts.

For me it was mostly login now. If you use reservations you should be fine, most likely will get seats lower B's depends where you flying. When I did checking from Dallas to NYC I got B15 which was awesome but from NyC to Dallas I got A35

So you're saying using the account method gives you a better chance at getting a better boarding position? If so, why is that?

No reservation and login makes no difference. I was just stating the fact that there is still good possibility to get good seats using this script :) depending where you flying to

Ah. Yep I feel pretty confident as long as the script gets a 200 on the first request. I will post the verbose once I run it in a few days :)

[jdholtz]

@dmytrokoren is this ready to be reviewed again or are the 403/429 mitigations still being worked on?

[dmytrokoren]

@dmytrokoren is this ready to be reviewed again or are the 403/429 mitigations still being worked on?

Ready for review. @jdholtz

[Bubba8291]

@dmytrokoren Looks like I won't be bypassing family boarding, but I still got something really good!

2024-08-06 13:23:18 DEBUG Process-1:1[checkin_handler:119]: Sleeping until check-in: 96 seconds... 2024-08-06 13:23:18 DEBUG Process-1:2[checkin_handler:101]: Sleeping until thirty minutes before check-in... 2024-08-06 13:23:19 DEBUG Process-1[checkin_scheduler:142]: 2 flights are currently scheduled. Removing old flights 2024-08-06 13:23:19 DEBUG Process-1[checkin_scheduler:161]: Successfully removed old flights. 2 flights are now scheduled ... Checking in to flight from 'A' to 'B' for me 2024-08-06 13:24:55 DEBUG Process-1:1[checkin_handler:169]: Attempting to check in 2024-08-06 13:24:55 DEBUG Process-1:1[checkin_handler:202]: Making GET request to check in 2024-08-06 13:24:56 DEBUG Process-1:1[utils:88]: Request error on attempt 1: Bad Request 400. Sleeping for 2.11 seconds until next attempt 2024-08-06 13:24:59 DEBUG Process-1:1[utils:88]: Request error on attempt 2: Bad Request 400. Sleeping for 1.71 seconds until next attempt 2024-08-06 13:25:05 DEBUG Process-1:1[utils:88]: Request error on attempt 3: Bad Request 400. Sleeping for 2.83 seconds until next attempt 2024-08-06 13:25:09 DEBUG Process-1:1[utils:68]: Successfully made request after 4 attempts 2024-08-06 13:25:09 DEBUG Process-1:1[checkin_handler:208]: Making POST request to check in 2024-08-06 13:25:11 DEBUG Process-1:1[utils:68]: Successfully made request after 1 attempts 2024-08-06 13:25:11 DEBUG Process-1:1[checkin_handler:179]: Successfully checked in after 1 attempts 2024-08-06 13:25:11 DEBUG Process-1:1[notification_handler:119]: Sending successful check-in notification... Successfully checked in to flight from 'A' to 'B' for me! I got B02!

What does the 400 come from in the Southwest API? If that 9 seconds was cut down to 3 - 5 seconds (or less), it could made a big difference.

[dmytrokoren]

@dmytrokoren Looks like I won't be bypassing family boarding, but I still got something really good!

2024-08-06 13:23:18 DEBUG Process-1:1[checkin_handler:119]: Sleeping until check-in: 96 seconds...

2024-08-06 13:23:18 DEBUG Process-1:2[checkin_handler:101]: Sleeping until thirty minutes before check-in...

2024-08-06 13:23:19 DEBUG Process-1[checkin_scheduler:142]: 2 flights are currently scheduled. Removing old flights

2024-08-06 13:23:19 DEBUG Process-1[checkin_scheduler:161]: Successfully removed old flights. 2 flights are now scheduled

...

Checking in to flight from 'A' to 'B' for me

2024-08-06 13:24:55 DEBUG Process-1:1[checkin_handler:169]: Attempting to check in

2024-08-06 13:24:55 DEBUG Process-1:1[checkin_handler:202]: Making GET request to check in

2024-08-06 13:24:56 DEBUG Process-1:1[utils:88]: Request error on attempt 1: Bad Request 400. Sleeping for 2.11 seconds until next attempt

2024-08-06 13:24:59 DEBUG Process-1:1[utils:88]: Request error on attempt 2: Bad Request 400. Sleeping for 1.71 seconds until next attempt

2024-08-06 13:25:05 DEBUG Process-1:1[utils:88]: Request error on attempt 3: Bad Request 400. Sleeping for 2.83 seconds until next attempt

2024-08-06 13:25:09 DEBUG Process-1:1[utils:68]: Successfully made request after 4 attempts

2024-08-06 13:25:09 DEBUG Process-1:1[checkin_handler:208]: Making POST request to check in

2024-08-06 13:25:11 DEBUG Process-1:1[utils:68]: Successfully made request after 1 attempts

2024-08-06 13:25:11 DEBUG Process-1:1[checkin_handler:179]: Successfully checked in after 1 attempts

2024-08-06 13:25:11 DEBUG Process-1:1[notification_handler:119]: Sending successful check-in notification...

Successfully checked in to flight from 'A' to 'B' for me!

I got B02!

What does the 400 come from in the Southwest API? If that 9 seconds was cut down to 3 - 5 seconds (or less), it could made a big difference.

B02 is good! Yes that time could be cut down, I was testing to avoid 400 bad request but @jdholtz had clarified that the script starts checkin 5 seconds before so 400 error is expected. It will go back to default 0.5 second every retry. You would of gotten ~A40's maybe

[Bubba8291]

@dmytrokoren Looks like I won't be bypassing family boarding, but I still got something really good!

2024-08-06 13:23:18 DEBUG Process-1:1[checkin_handler:119]: Sleeping until check-in: 96 seconds...

2024-08-06 13:23:18 DEBUG Process-1:2[checkin_handler:101]: Sleeping until thirty minutes before check-in... 2024-08-06 13:23:19 DEBUG Process-1[checkin_scheduler:142]: 2 flights are currently scheduled. Removing old flights 2024-08-06 13:23:19 DEBUG Process-1[checkin_scheduler:161]: Successfully removed old flights. 2 flights are now scheduled ... Checking in to flight from 'A' to 'B' for me 2024-08-06 13:24:55 DEBUG Process-1:1[checkin_handler:169]: Attempting to check in 2024-08-06 13:24:55 DEBUG Process-1:1[checkin_handler:202]: Making GET request to check in 2024-08-06 13:24:56 DEBUG Process-1:1[utils:88]: Request error on attempt 1: Bad Request 400. Sleeping for 2.11 seconds until next attempt 2024-08-06 13:24:59 DEBUG Process-1:1[utils:88]: Request error on attempt 2: Bad Request 400. Sleeping for 1.71 seconds until next attempt 2024-08-06 13:25:05 DEBUG Process-1:1[utils:88]: Request error on attempt 3: Bad Request 400. Sleeping for 2.83 seconds until next attempt 2024-08-06 13:25:09 DEBUG Process-1:1[utils:68]: Successfully made request after 4 attempts 2024-08-06 13:25:09 DEBUG Process-1:1[checkin_handler:208]: Making POST request to check in 2024-08-06 13:25:11 DEBUG Process-1:1[utils:68]: Successfully made request after 1 attempts 2024-08-06 13:25:11 DEBUG Process-1:1[checkin_handler:179]: Successfully checked in after 1 attempts 2024-08-06 13:25:11 DEBUG Process-1:1[notification_handler:119]: Sending successful check-in notification... Successfully checked in to flight from 'A' to 'B' for me! I got B02! What does the 400 come from in the Southwest API? If that 9 seconds was cut down to 3 - 5 seconds (or less), it could made a big difference.

B02 is good! Yes that time could be cut down, I was testing to avoid 400 bad request but @jdholtz had clarified that the script starts checkin 5 seconds before so 400 error is expected. It will go back to default 0.5 second every retry. You would of gotten ~A40's maybe

But the logs says that it actually went up, not stayed at 0.5.

[dmytrokoren]

But the logs says that it actually went up, not stayed at 0.5.

Yes, because it's currently set at random_sleep from 1 to 3 seconds. Will remove that and put back 0.5 seconds

[jdholtz]

Hey @dmytrokoren, while running the Docker image, it is hanging for me at Starting webdriver for current session. Same issue while running the container with --privileged. Here are the logs to help you debug:

...
2024-08-15 02:21:18 DEBUG MainProcess[main:80]: Adding account through CLI arguments
2024-08-15 02:21:18 DEBUG MainProcess[config:144]: Creating configurations for 1 accounts
2024-08-15 02:21:18 INFO MainProcess[main:97]: Monitoring 1 account and 0 reservations

2024-08-15 02:21:18 DEBUG Process-1[reservation_monitor:58]: Acquiring lock...
2024-08-15 02:21:18 DEBUG Process-1[reservation_monitor:60]: Lock acquired
2024-08-15 02:21:18 DEBUG Process-1[reservation_monitor:198]: Retrieving reservations for account
2024-08-15 02:21:18 DEBUG Process-1[webdriver:142]: Starting virtual display for current session
2024-08-15 02:21:18 DEBUG Process-1[webdriver:147]: Started virtual display successfully
2024-08-15 02:21:18 DEBUG Process-1[webdriver:153]: Starting webdriver for current session

[dmytrokoren]

Hey @dmytrokoren, while running the Docker image, it is hanging for me at Starting webdriver for current session. Same issue while running the container with --privileged. Here are the logs to help you debug:

...

2024-08-15 02:21:18 DEBUG MainProcess[main:80]: Adding account through CLI arguments

2024-08-15 02:21:18 DEBUG MainProcess[config:144]: Creating configurations for 1 accounts

2024-08-15 02:21:18 INFO MainProcess[main:97]: Monitoring 1 account and 0 reservations

2024-08-15 02:21:18 DEBUG Process-1[reservation_monitor:58]: Acquiring lock...

2024-08-15 02:21:18 DEBUG Process-1[reservation_monitor:60]: Lock acquired

2024-08-15 02:21:18 DEBUG Process-1[reservation_monitor:198]: Retrieving reservations for account

2024-08-15 02:21:18 DEBUG Process-1[webdriver:142]: Starting virtual display for current session

2024-08-15 02:21:18 DEBUG Process-1[webdriver:147]: Started virtual display successfully

2024-08-15 02:21:18 DEBUG Process-1[webdriver:153]: Starting webdriver for current session

Hey @jdholtz yes I'm testing right now to see how to fix it. I'm seeing the same thing.

[jdholtz]

Yes that time could be cut down, I was testing to avoid 400 bad request but @jdholtz had clarified that the script starts checkin 5 seconds before so 400 error is expected

Starting 5 seconds early was a decision I made without much evidence backing up that it actually makes the check-in faster and/or more reliable (it was in a previous Southwest check-in script that no longer works). I'm definitely in favor of removing this early start time if it someone wants to test to see if the check-in is not worse (and it may be even better).

[jdholtz]

Hey @jdholtz yes I'm testing right now to see how to fix it. I'm seeing the same thing.

Also, it would be great to have some people who are running into the 403/429s to test these changes as I am not currently seeing any issues on the develop branch. That way, it can be verified that these changes do help avoid detection.

[dmytrokoren]

Hey @jdholtz yes I'm testing right now to see how to fix it. I'm seeing the same thing.

Also, it would be great to have some people who are running into the 403/429s to test these changes as I am not currently seeing any issues on the develop branch. That way, it can be verified that these changes do help avoid detection.

Yes, develop branch seems to be stable now.

[jdholtz]

Hey @dmytrokoren, while running the Docker image, it is hanging for me at Starting webdriver for current session. Same issue while running the container with --privileged. Here are the logs to help you debug:

@dmytrokoren this actually seems to be a bug/incompatibility with the Python 3.12-alpine Docker image. It’s being worked on in #290 right now, but changing the base image to python:3.12-rc-alpine fixed the issue and I can log in and schedule flights successfully.

[dmytrokoren]

Hey @dmytrokoren, while running the Docker image, it is hanging for me at Starting webdriver for current session. Same issue while running the container with --privileged. Here are the logs to help you debug:

@dmytrokoren this actually seems to be a bug/incompatibility with the Python 3.12-alpine Docker image. It’s being worked on in #290 right now, but changing the base image to python:3.12-rc-alpine fixed the issue and I can log in and schedule flights successfully.

Good find. @jdholtz I'll check on my end too.

[dmytrokoren]

Hey @jdholtz - I made the changes in my new branch (not yet raised PR) -

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

Please test on your end, let me know.

Changes:

1. Dockerfile what is already raised in PR but including 'sbvirtualdisplay'
2. requirements.txt updated to latest change
3. Using "page_load_strategy": "none" - so that we don't have to wait until mobile.southwest.com fully loads. Also using direct link to check-in page so no click is required.

[Bubba8291]

@dmytrokoren my checkin is in 5 hours. I will be asleep, so I won't see what happened until I wake up. Should I pull the recent changes before I hit the hay?

Edit: Should've mentioned. I have a corn job that starts it 5 min before. It will also log the debug output to a file.

[dmytrokoren]

@dmytrokoren my checkin is in 5 hours. I will be asleep, so I won't see what happened until I wake up. Should I pull the recent changes before I hit the hay?

Edit: Should've mentioned. I have a corn job that starts it 5 min before. It will also log the debug output to a file.

@Bubba8291 not yet. Let me make one more change I'll send a message allow 15 min

[Bubba8291]

@dmytrokoren do I have the green light?

[dmytrokoren]

@dmytrokoren do I have the green light?

5 min

[Bubba8291]

@dmytrokoren do I have the green light?

5 min

Alright 👍

[dmytrokoren]

@Bubba8291 pull latest docker tag: alpha from my repo

[Bubba8291]

@Bubba8291 pull latest docker tag: alpha from my repo

Thank you! Btw, I just use git pull on my headless container. I don't use Docker.

I'll let you know what I get

[dmytrokoren]

@Bubba8291 pull latest docker tag: alpha from my repo

Thank you! Btw, I just use git pull on my headless container. I don't use Docker.

I'll let you know what I get

Sounds good! Thanks for testing

[dmytrokoren]

@Bubba8291 pull latest docker tag: alpha from my repo

Thank you! Btw, I just use git pull on my headless container. I don't use Docker.

I'll let you know what I get

@Bubba8291 use this branch from my repo... 'new_dev' has all latest changes

dmytrokoren/auto-southwest-check-in

[Bubba8291]

@Bubba8291 pull latest docker tag: alpha from my repo

Thank you! Btw, I just use git pull on my headless container. I don't use Docker.

I'll let you know what I get

@Bubba8291 use this branch from my repo... 'new_dev' has all latest changes

dmytrokoren/auto-southwest-check-in

@dmytrokoren Oh I just checked out the branch in the PR. But it says something about new_dev in the pull.

Does everything look right? I also ran pip install for the new requirements in the pull.

[dmytrokoren]

@Bubba8291 pull latest docker tag: alpha from my repo

Thank you! Btw, I just use git pull on my headless container. I don't use Docker.

I'll let you know what I get

@Bubba8291 use this branch from my repo... 'new_dev' has all latest changes

dmytrokoren/auto-southwest-check-in

@dmytrokoren Oh I just checked out the branch in the PR. But it says something about new_dev in the pull.

Does everything look right? I also ran pip install for the new requirements in the pull.

Yes that's correct. Do git pull once more and checkout 'new_dev'

[Bubba8291]

@Bubba8291 pull latest docker tag: alpha from my repo

Thank you! Btw, I just use git pull on my headless container. I don't use Docker.

I'll let you know what I get

@Bubba8291 use this branch from my repo... 'new_dev' has all latest changes

dmytrokoren/auto-southwest-check-in

@dmytrokoren Oh I just checked out the branch in the PR. But it says something about new_dev in the pull.

Does everything look right? I also ran pip install for the new requirements in the pull.

Yes that's correct. Do git pull once more and checkout 'new_dev'

Done! We will see what happens in a few hours :)

[Bubba8291]

@dmytrokoren Very good news today! A23! Though A23 after 10 seconds makes me think it's an empty flight. However, it is a 7am flight. But you'd think people would get early bird for this reason. Btw, I did not get early bird and my fare is WGA.

2024-08-15 04:50:19 DEBUG Process-1[reservation_monitor:71]: Lock released 2024-08-15 04:50:19 DEBUG Process-1[reservation_monitor:144]: Sleeping for 86381 seconds 2024-08-15 04:54:55 DEBUG Process-1:1[checkin_handler:169]: Attempting to check in 2024-08-15 04:54:55 DEBUG Process-1:1[checkin_handler:204]: Making POST request to check in 2024-08-15 04:54:56 DEBUG Process-1:1[utils:89]: Request error on attempt 1: Bad Request 400. Sleeping for 0.50 seconds until next attempt 2024-08-15 04:54:58 DEBUG Process-1:1[utils:89]: Request error on attempt 2: Bad Request 400. Sleeping for 0.50 seconds until next attempt 2024-08-15 04:54:59 DEBUG Process-1:1[utils:89]: Request error on attempt 3: Bad Request 400. Sleeping for 0.50 seconds until next attempt 2024-08-15 04:55:03 DEBUG Process-1:1[utils:89]: Request error on attempt 4: Bad Request 400. Sleeping for 0.50 seconds until next attempt 2024-08-15 04:55:08 DEBUG Process-1:1[utils:69]: Successfully made request after 5 attempts 2024-08-15 04:55:08 DEBUG Process-1:1[checkin_handler:210]: Making POST request to check in 2024-08-15 04:55:10 DEBUG Process-1:1[utils:69]: Successfully made request after 1 attempts 2024-08-15 04:55:10 DEBUG Process-1:1[checkin_handler:179]: Successfully checked in after 1 attempts 2024-08-15 04:55:10 DEBUG Process-1:1[notification_handler:119]: Sending successful check-in notification... Checking in to flight from 'A' to 'B' for me Successfully checked in to flight from 'A' to 'B' for me! I got A23!

[dmytrokoren]

@dmytrokoren Very good news today! A23! Though A23 after 10 seconds makes me think it's an empty flight. However, it is a 7am flight. But you'd think people would get early bird for this reason. Btw, I did not get early bird and my fare is WGA.

2024-08-15 04:50:19 DEBUG Process-1[reservation_monitor:71]: Lock released 2024-08-15 04:50:19 DEBUG Process-1[reservation_monitor:144]: Sleeping for 86381 seconds 2024-08-15 04:54:55 DEBUG Process-1:1[checkin_handler:169]: Attempting to check in 2024-08-15 04:54:55 DEBUG Process-1:1[checkin_handler:204]: Making POST request to check in 2024-08-15 04:54:56 DEBUG Process-1:1[utils:89]: Request error on attempt 1: Bad Request 400. Sleeping for 0.50 seconds until next attempt 2024-08-15 04:54:58 DEBUG Process-1:1[utils:89]: Request error on attempt 2: Bad Request 400. Sleeping for 0.50 seconds until next attempt 2024-08-15 04:54:59 DEBUG Process-1:1[utils:89]: Request error on attempt 3: Bad Request 400. Sleeping for 0.50 seconds until next attempt 2024-08-15 04:55:03 DEBUG Process-1:1[utils:89]: Request error on attempt 4: Bad Request 400. Sleeping for 0.50 seconds until next attempt 2024-08-15 04:55:08 DEBUG Process-1:1[utils:69]: Successfully made request after 5 attempts 2024-08-15 04:55:08 DEBUG Process-1:1[checkin_handler:210]: Making POST request to check in 2024-08-15 04:55:10 DEBUG Process-1:1[utils:69]: Successfully made request after 1 attempts 2024-08-15 04:55:10 DEBUG Process-1:1[checkin_handler:179]: Successfully checked in after 1 attempts 2024-08-15 04:55:10 DEBUG Process-1:1[notification_handler:119]: Sending successful check-in notification... Checking in to flight from 'A' to 'B' for me Successfully checked in to flight from 'A' to 'B' for me! I got A23!

That is a good seat position. Let us know if the flight is empty or not :)

[dmytrokoren]

@jdholtz - this is the all the changes that is currently in PR in your repo - https://github.com/jdholtz/auto-southwest-check-in/compare/develop...dmytrokoren:auto-southwest-check-in:new_dev

as @Bubba8291 mentioned its working fine. I also ran overnight in docker and had no login issue or check fare issues. What you think?

[jdholtz]

@Bubba8291 are you getting 403/429 errors on the latest develop changes (without any of dmytrokoren’s changes)?

[dmytrokoren]

@Bubba8291 are you getting 403/429 errors on the latest develop changes (without any of dmytrokoren’s changes)?

@jdholtz, he is not running in docker, and he is using only reservations not login - from what I understood. (My changes are using xvfb so we can run headed in docker.)

[Bubba8291]

@Bubba8291 are you getting 403/429 errors on the latest develop changes (without any of dmytrokoren’s changes)?

@jdholtz @dmytrokoren

Logs from jdholtz develop branch Logs from dmytrokoren new_dev branch

Seems like neither had any issues re running both of them. And yes, I am pulling the repo and checking out the branches without docker. I also made sure to grab the dependencies for each repo before running the checkin scripts.

The only errors I've gotten consistently are 400 errors. My initial checkin had them. And when I was testing the script last night, I was getting 400 errors on the fare_checker, which ended up never getting a 200 response.

[dmytrokoren]

@Bubba8291 are you getting 403/429 errors on the latest develop changes (without any of dmytrokoren’s changes)?

@jdholtz @dmytrokoren

Logs from jdholtz develop branch Logs from dmytrokoren new_dev branch

Seems like neither had any issues re running both of them. And yes, I am pulling the repo and checking out the branches without docker. I also made sure to grab the dependencies for each repo before running the checkin scripts.

The only errors I've gotten consistently are 400 errors. My initial checkin had them. And when I was testing the script last night, I was getting 400 errors on the fare_checker, which ended up never getting a 200 response.

From the both reports I do not see 400 error. 400 is Bad Request - I only saw that this morning from your screenshot when you got A23 position. But 400 is expected on check-in but I did not see on fare-check.

[dmytrokoren]

Hey @jdholtz what we doing with this PR, any changes or suggestions?

[jdholtz]

Hey @jdholtz what we doing with this PR, any changes or suggestions?

I want to see if anyone who is currently getting 403/429 errors on v8.0 has no errors with these changes. Otherwise, we should work on it a bit more so users can successfully avoid 403 and 429 errors.