feat(cts): test the timeouts of the retry stragety #3264
Conversation
| } | ||
| break; | ||
| default: | ||
| // the delay should be the same, because the `retryCount` is per host instead of global |
There was a problem hiding this comment.
shouldn't the default be exponential?
There was a problem hiding this comment.
idk what's expected but it feels weird to me to retry instantly
There was a problem hiding this comment.
yeah almost all clients behave like this except for php and js, basically the retryCount is per host so the delay will increase on the next request, not on the next host, so the delay is the same.
If we run a second query in this test, we will see increased delay, but then the test will take too long.
There was a problem hiding this comment.
ah so:
- query search
- fails, retried on all hosts with no exponential delay between hosts
- query search again
- fails, retried with increased delay, still not exponential between hosts
? this seems wrong to me because we assume the user retries but it's the client that should handle all that 🤔
There was a problem hiding this comment.
yeah its weird, but it was like that in legacy clients, this PR aims at checking the logic, not fixing every client as it would be very complicated
There was a problem hiding this comment.
yup my comment doens't block it, I'm trying to understand if we should fix that before GA
I think we should ask the search team for advices and harmonize everything
There was a problem hiding this comment.
if we have time yes, it shouldn't be a breaking change to modify this logic
✔️ Code generated!
|
🧭 What and Why
🎟 JIRA Ticket: APIC-587
Use the test server to verify that the client uses the correct timeouts and delays.