21Bruce
[INFO]: Bot will be down for at least three weeks
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.
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
@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 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.
Hey @bharrison21 , was wondering if you had an update. anything i could look into to help?
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
@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
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.
@khaullen Would you like to take a stab at reproducing on postman? Or maybe a commit?
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.