-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Possible race condition with JUnit 5 in 1.16.1 and 1.16.2 #4679
Comments
Hey @SanityResort, thanks for reporting. Did you only observe this for RabbitMQ, or also other images? And can you reproduce it when manually starting the container, instead of using the JUnit5 extension?
|
Thanks for the quick reply. Currently we are only using I will have a look if I can change the tests to run without the JUnit5 extension and will get back at you ASAP. |
You are using |
Acutally no. We are creating a
From what you write this could very well be the issue as the the I will try to change our test accordingly. |
In this case, you are using the default host port wait strategy. This might very well not be a good indicator for RabbitMQ being actually started. Since we improved the performance of this check, it might have indeed led to your race condition. However, this just highlighted an existing race condition based on wrong assumptions. Let me know if using the dedicated module or switching the wait strategies helps with your problem 🙂 |
Indeed using Thanks a lot for your help and sorry for this inconvenience. |
Awesome, great that it works for you now 👍 |
When trying to upgrade from
1.15.3
to1.16.2
we encountered an issue breaking our tests that might be a race condition.It seems that connecting to the exposed port is not possible yet when the test cases are executed. Adding timeouts to the
@BeforeEach
method does reduce these errors which would suggest a race condition here.I did have a look at PR 4597 and the linked issues. Maybe these could be related but cannot say for sure.
So far I have not been able to create a local reproducer but adding debug logging produces the following output:
This shows a run of three tests starting a container with a
rabbitmq:3.8
image, in our tests we try to connect to that container during the@BeforeEach
setup method (Moving this call to the actual test method did not solve the issue). The first test results in an error where as the other two complete successfully. We have also seen runs with all three tests failing.From the log output it would seem the container is up and running before the test gets executed, the actual behaviour suggests differently. With
1.16.0
or1.15.3
we did not observe any similar issues.Connection reset
could also imply that the container was shutting down again already but that would be unexpected during the test setup and adding timeout at the start of the setup method should not have an effect on it.Changing to a shared container instance for all tests did also not solve the issue.
Please let me know if you require any further information.
The text was updated successfully, but these errors were encountered: