To prevent over-exploitation of LambdaTest, we have added a capacity constraint on the number of tests that can be queued at our platform. The maximum number of elements that are allowed to be queued for your LambdaTest account will depend upon the number of concurrent sessions you are eligible for. You can figure out the maximum number of test cases you are allowed to queue with the below formula.
Maximum number of test cases that can be queued = n + 150
Here, n = number of concurrent sessions.
Here is an example, if your LambdaTest account is eligible for 10 concurrent sessions, then your queue can have a maximum of (10 + 150) queued test cases i.e. 160 queued test cases. The scheduling and execution of test cases in your queue will be taken care of by LambdaTest.
If more tests are sent for execution than allowed by your concurrency limit then they will be put in a queue until the queue reaches its maximum holding capacity. So, if you have a concurrency of 100 but you send 200 tests, the “extra” tests will be queued and run as the first round of tests finish. In this scenario, when the number of running tests drops to 99, 1 test from the queue will start running, and when the next test finishes, another test from the queue will start running. This continues until all the queued tests are executed.
Keep in mind the below key points before you start queuing your automated test cases using LambdaTest Selenium grid.
An account can breach allowed queuing limit 7 times in a month, Example an account has 100 concurrent session plan so that he is allowed to put n+150=250 requests in the queue. If he tries to exceed the limit then the requests will get rejected. Rejection events are counted monthly at the account level. So. user is allowed to request (n+150)*x (default 7 in a month) (where x is a constant per account) before suspending the account.