-
Notifications
You must be signed in to change notification settings - Fork 323
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
Incorrect status code in case of "Too many requests" response #1203
Comments
@eGavr no such status code in W3C standard. https://www.w3.org/TR/webdriver/#errors |
Yes, you are right. But how can we determine that the error reason is "Too many requests"? This value is in error message, but I think relying for this value in error message is not a good idea. |
@eGavr should rely on |
The full error is
"unknown error" is not concrete error which cannot be associated with the original reason about "Queue Is Full" (I mean that in my program code I need to distinguish unknown errors and error because of full queue) |
@eGavr probably we can introduce a new error code that is not included to the standard. |
Until version 1.10.7 selenoid has an error that is not included to the standard, and this error was with status code 429 :) |
That error code needs only for ggr, and can be disabled by command line
option. Selenoid was developed when w3c standard did not exist.
вт, 29 мар. 2022 г., 10:46 Evgeniy Gavryushin ***@***.***>:
… Until version 1.10.7 selenoid has an error that is not included to the
standard, and this error was with status code 429 :)
—
Reply to this email directly, view it on GitHub
<#1203 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKY23NEZBTCKDHJ2V6Y763VCKYOPANCNFSM5ROFTUDA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Can we do this? To tell the truth, it seems that since status code 429 disappeared backward compatibility has been broken in 1.x |
Selenoid version: 1.10.7
Broken since selenoid version: 1.10.7
Run selenoid with options
-disable-queue -limit 5
Current behaviour:
Expected behaviour:
JFYI. In out team we've hacked the problem this way.
The text was updated successfully, but these errors were encountered: