-
Notifications
You must be signed in to change notification settings - Fork 10
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
[BUG]: bot not firing? #33
Comments
Did you run list twice? list is not an in-place operation, i.e., you must run the command again to see if the status of anything updates, and there is often some delay between when the changes in events happen and when they are caught by list |
Yes, of course.
Best,
Dora
914-523-7381
…On Tue, Feb 20, 2024 at 12:40 PM Bruce Jagid ***@***.***> wrote:
Did you run list twice? list is not an in-place operation, i.e., you must
run the command again to see if the status of anything updates
—
Reply to this email directly, view it on GitHub
<#33 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BGHN5645RBTFME7FXJ67CQDYUTNYDAVCNFSM6AAAAABDNRZQO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJUG4YTSMBZGM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
@DoraGor Both me and the other dev have been really busy with school stuff the past two weekends. I'm unsure what's causing this new bug, could be resy using captcha or a bug in the new table type code. Either way, I think you should try cloning an older version of the bot. I think commit 60e88dd should be working if it were an issue with the table type code. If you try this and it doesn't work, then I'd really have to sit down and analyze the network response from the api layer |
I will try this and get back to you, but you should know I didn't use the
table types at all.
…On Fri, Feb 23, 2024, 9:27 AM Bruce Jagid ***@***.***> wrote:
@DoraGor <https://github.com/DoraGor> Both me and the other dev have been
really busy with school stuff the past two weekends. I'm unsure what's
causing this new bug, could be resy using captcha or a bug in the new table
type code. Either way, I think you should try cloning an older version of
the bot. I think commit 60e88dd
<60e88dd>
should be working if it were an issue with the table type code. If you try
this and it doesn't work, then I'd really have to sit down and analyze the
network response from the api layer
—
Reply to this email directly, view it on GitHub
<#33 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BGHN56777DIOVQVPSPPXMDTYVCRN5AVCNFSM6AAAAABDNRZQO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRRGQZDOOJVGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I understand that from your post, but the table type code is still part of the underlying networking routine to make a reservation with resy, so it still might influence it even if table types aren't set. It could just be a bug with the code that we didn't catch in testing |
Is there an existing issue for this bug?
Description of the bug
for some reason the bot doesn't seem to be working. I put 3 requests in, two of which have passed and should have fired. yet when I request a list, it says all three are still in progress.
Steps to reproduce
I used semma and via carota as the two restaurants, filled in reqD of 2.15 and 2.17 at midnight. now 3pm on 2.17 and neither have fired.
System Specs
macos ventura
Additional Context
No response
The text was updated successfully, but these errors were encountered: