Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[INFO]: Bot will be down for at least three weeks #35

Open
21Bruce opened this issue Mar 6, 2024 · 10 comments
Open

[INFO]: Bot will be down for at least three weeks #35

21Bruce opened this issue Mar 6, 2024 · 10 comments
Assignees
Labels
bug Something isn't working critical Issue may affect fundamental functionality documentation Improvements or additions to documentation help wanted Extra attention is needed information This issue is a note describing general information

Comments

@21Bruce
Copy link
Owner

21Bruce commented Mar 6, 2024

Information to share

There's been a lot of posting and emailing about more or less the same bug/issue. Initially I thought this bug was related to the most recent changes adding table type selection to the bot, but even reverting to a version from a month ago(which was working perfectly fine), the error persists. This is alarming, since it means that something on Resy's side changed and that's causing the bug. I've done a preliminary analysis using some println debugging and reviewing the API in firefox and I've deduced two possibilities. 1) The API for the config step has changed, I'll perform some analysis on this the next free moment I have. 2) Resy has increased their use of Captcha, and this is blocking the bot. I personally think 2) is more likely than 1). Regardless, I can't look at 1) till I get a break around three weeks from now, so the bot will be non-functional until that time unless a user is curious enough to look at the code.

IF YOU PLAN TO SOLVE THE PROBLEM:
I've taken a quick look at this bug. The network error occurs on line 366 in api/resy/api.go . The status code returned is 500. For anyone whose looked in the source files, this occurs at the config step of the reserve api operation. I checked to make sure the api key in the codebase is still valid and tried adding a user agent header. These didn't fix the issue.

@21Bruce 21Bruce added bug Something isn't working documentation Improvements or additions to documentation help wanted Extra attention is needed critical Issue may affect fundamental functionality information This issue is a note describing general information labels Mar 6, 2024
@21Bruce 21Bruce self-assigned this Mar 6, 2024
@21Bruce 21Bruce pinned this issue Mar 6, 2024
@bharrison21
Copy link

Thanks for sharing this project. It's looking strong. I was wondering if you have an update on the bug fixes.

-A very eager resy user

@21Bruce
Copy link
Owner Author

21Bruce commented Apr 29, 2024

@bharrison21 To quote the recent discussion post "atm the other dev and I have more or less moved on". I might look at some improvements over the summer depending on time, but unlikely. However, I will still review any code diffs that come my way.

@bharrison21
Copy link

Brutal. Love the project.

I'll do a dive in.

@21Bruce
Copy link
Owner Author

21Bruce commented Apr 29, 2024

@bharrison21 Sounds good. A good tip is to use postman + firefox network tab to analyze the resy web api. If you look in the file /api/resy/api.go /api/resy/doc.go, it's essentially one large comment documenting how we think the resy api works, so to debug this, you essentially wanna figure out where the actual resy web api is diverging from that, since that comment determines how our code works w/ resy essentially.
If you have a commit, email the diff to me along with some tests confirming that it works as intended, and I'll commit them for you. If you make enough commits, I'll even name you as a contributor with commit access.

@dh-verma
Copy link

Hey @bharrison21 , was wondering if you had an update. anything i could look into to help?

@khaullen
Copy link

Is this 500 error intermittent, or contingent on originating IP address? I've been seeing behavior in the Resy API recently that suggests requests may be getting blocked by AWS WAF

@21Bruce
Copy link
Owner Author

21Bruce commented May 15, 2024

@khaullen What behavior have you seen to suggest this? On your original question, I haven't done much testing let alone on if the originating IP matters, though I think that could be important

@khaullen
Copy link

When issuing repeated requests for availability on successive days (via Zapier), there's a clear pattern in the logs of 500 responses gradually increasing in prevalence for the exact same API request, to the point now where it seems 100% reproducible via Zapier, yet not reproducible at all when the same request is issued via Postman.

@21Bruce
Copy link
Owner Author

21Bruce commented May 15, 2024

@khaullen Would you like to take a stab at reproducing on postman? Or maybe a commit?

@khaullen
Copy link

My focus is currently on scraping, but I'll for sure update this thread with any new findings and push a PR if I find a solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working critical Issue may affect fundamental functionality documentation Improvements or additions to documentation help wanted Extra attention is needed information This issue is a note describing general information
Projects
None yet
Development

No branches or pull requests

4 participants