-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
HttpWaitStrategy.forStatusCodeMatching always expect 200 code #880
Labels
Comments
Good catch, I assume you encountered it while using it? 😉 |
dadoonet
referenced
this issue
in dadoonet/testcontainers-java
Sep 24, 2018
….forStatusCode In #630 we introduced predicates but with a default one which is always present whatever what is passed in the `forStatusCodeMatching()` method. This commit adds a test that demonstrates the issue: * We have a service returning `200 OK` * The predicate expects anything which is a code >= to `300` * The test should throw a Timeout as this condition is never reached but without the current fix, the test never throws the Timeout as 200 matches the default builtin predicate. This commit fixes the problem by checking at startup time what is/are the predicates that needs to be applied. Note that in most cases, an HTTP service is expected to throw a `200 OK` status so that fix might not fix actually any real problem and might be a theory only. But I'd prefer to have code that actually implements what is supposed to work. Closes #880.
rnorth
pushed a commit
that referenced
this issue
Sep 25, 2018
….forStatusCode (#881) In #630 we introduced predicates but with a default one which is always present whatever is passed in the `forStatusCodeMatching()` method. This commit adds a test that demonstrates the issue: * We have a service returning `200 OK` * The predicate expects anything which is a code >= to `300` * The test should throw a Timeout as this condition is never reached but without the current fix, the test never throws the Timeout as 200 matches the default builtin predicate. This commit fixes the problem by checking at startup time what is/are the predicates that needs to be applied. Note that in most cases, an HTTP service is expected to throw a `200 OK` status so that fix might not fix actually any real problem and might be a theory only. But I'd prefer to have code that actually implements what is supposed to work. Closes #880.
kiview
added
resolution/awaiting-release
and removed
resolution/acknowledged
resolution/awaiting-release
labels
Sep 25, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I did a mistake while implementing #630.
We have by default this predicate:
Then we test the status code using:
This means that code 200 is always considered as a "good" status code.
Where I'd expect the developper to provide it explicitly.
I mean that:
Should only match
HTTP_UNAUTHORIZED
and notHTTP_OK
.I'll come with a fix.
The text was updated successfully, but these errors were encountered: