However, you’re supposed to simulate user behavior. IMHO, if the login sometimes fails once under load, a typical user doesn’t definitively give up, he… retries (and usually by clicking like crazy)!
Well, my 2 cents is that if you ask people about these 3 options, you will get 33,33% / 33,33% / 33,33%…
Should “stopOnError” be a global config or specific to a given request?
Should “retry” be applied on a single request or a chain (for example, login is not necessarily a single request process, but can generate multiple requests, like with CAS)?
Complex topic actually…
“retry” and “stopOnError” built-ins could be good ideas, but I’d rather not rush but take time to make sure they’re indeed good ones.
Introducing something in the DSL (which is our public API) is something we want to carefully design. We broke some things between 1.0 and 1.1 because of design mistakes and it was painful for some users.
The best way to have this topic move forward is having other people joining in the discussion (“hey, anybody here???”).
No rush for me and I fully agree that any DSL changes should be discussed
Should “stopOnError” be a global config or specific to a given request?
I would think both
Should “retry” be applied on a single request or a chain (for example, login is not necessarily a single request process, but can generate multiple requests, like with CAS)?
In case of a chain, I would think that the “retry” only applies on the last request.