-
Notifications
You must be signed in to change notification settings - Fork 107
Open
Description
The issue is inspired by comment #960 (review) and #962 . It seems some existing test(s) must be enhanced to catch and check the cases for keeping request/response sequence:
- a request blocked due to a parser error
- a request blocked by Frang
- response length is determined by connection closing and doesn't correspond
Content-Length
value for the response - response is blocked due to a parser error
All the cases must be tested with checking sequence of pipelined requests and received responses. Moreover, all the tests must be checked in 2 modes:
- configured error responses - error/unlucky requests must receive error responses
- configured blocking - client connections must be terminated on error/unlucky requests while all previous requests should receive responses.
The very last requirement can be broken under high concurrency and previous requests also can be unanswered (i.e. the case will be seen as a previous request was blocked), so it has sense to not to use stress testing here.
UPD. Also please add tests for non-idempotent requests, in particular test server_retry_nonidempotent
and nonidempotent
configuration options:
- a client sends a request just after non-idempotent request, then both the request must be normally pipelined.
- if several requests in a server queue must be rescheduled due to the server failure, then a non-idempotent request must not be resent and an error response corresponding to the request must be sent to the client
Also fix the disabled tests for the issue.