-
-
Notifications
You must be signed in to change notification settings - Fork 512
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
Verify Reaper state to create new or return existing instance #782
Verify Reaper state to create new or return existing instance #782
Conversation
✅ Deploy Preview for testcontainers-go ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
@mdelapenya this is the PR for better Reaper consistency. I opted to use the |
Fix linting errors
409d431
to
02a5664
Compare
@mdelapenya it seems like this PR is awaiting approval to run tests (again?). Maybe because I fixed a linting error and then rebased and pushed again? |
Sorry for the merge conflicts 😞 , we needed to extract the calculation of the docker host to an internal package as part of certain refactors (#796). Do you want me to resolve them? |
…n-failure-or-exit * origin/main: docs: add intel as user (testcontainers#798) chore: bump containerd in examples (testcontainers#797) chore(deps): bump github.com/containerd/containerd from 1.6.15 to 1.6.16 (testcontainers#793) chore: extract docker host calculation to an internal package (testcontainers#796) chore: run "go mod tidy" automatically when creating examples (testcontainers#794) chore: build images with backoff retries (testcontainers#792)
Conflicts resolved. Wasn't that bad luckily :-) |
// If reaper already exists and healthy, re-use it | ||
if reaperInstance != nil { | ||
// Verify this instance is still running by checking state. | ||
// Can't use Container.IsRunning because the bool is not updated when Reaper is terminated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Meanwhile the CI runs (tests will pass) can you elaborate a bit on this comment? Do you think that bool should be updated in consequence (probably here? in a follow-up?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the Container.IsRunning
is simply a boolean flag (
Line 63 in fb64671
isRunning bool |
Line 233 in fb64671
c.isRunning = false |
Stop()
or Terminate()
methods. Instead, it terminates automatically by itself by closing the connection to it (Line 241 in fb64671
case c.terminationSignal <- true: |
Which makes the
IsRunning()
unreliable for the Reaper container as it would never return false
.
That's why I chose to poll Docker and get the state from there, as it should be reliable.
What I think would be better, is if the IsRunning()
method (
Line 89 in fb64671
func (c *DockerContainer) IsRunning() bool { |
I did not want to touch this code in the PR because I don't know the history behind it. Perhaps
IsRunning
is regularly checked and would be relatively heavy on the Docker calls?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, thanks for such a clear explanation, now I see what you mean.
I think checking the state from Docker would be more accurate than the one we have now, and I understand your concerns about performance if that method is called many times. I've checked their usages and are just a few of them at this moment (particularly worried on the GenericContainer function calling it).
Adding that code, we could also take the situation to a place where multiple goroutines in tests are trying to read the container state at the same time, and one decides to see it as not running, and the next one as running, which could be worse.
I'd keep this simple as in your submission, and evaluate if we need to check for the state more frequently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shaun approves 😎
This comment does not affect the review, so will eventually merge this one today
Thank you very much for your support!
Mmm I've checkout out the PR locally to verify one weird behaviour that I'm seeing in another issue, which happens when there are multiple packages in the Go project running the tests. How go test works is that it runs each package separately, creating as many Ryuk containers as packages in the execution. I've verified that even with this PR, there are multiple Ryuk containers. Let me do some verifications on accessing the mutex and will let you know asap |
This is the expected behaviour of Said that, if you agree, we can merge this one, as it covers the scenario of running just one reaper instance per test binary. |
All good from my side. Would be happy to have it merged. |
* main: chore: update Docker labels for containers (testcontainers#813) fix: nil pointer dereference in HealthStrategy (testcontainers#802) fix: Synchronise writes to containers map (testcontainers#812) chore(deps): bump google.golang.org/api from 0.108.0 to 0.109.0 in /examples (testcontainers#810) chore(deps): bump cloud.google.com/go/spanner in /examples/spanner (testcontainers#806) chore: restructure Docker helper methods (testcontainers#799) Verify Reaper state to create new or return existing instance (testcontainers#782) docs: add intel as user (testcontainers#798) chore: bump containerd in examples (testcontainers#797) chore(deps): bump github.com/containerd/containerd from 1.6.15 to 1.6.16 (testcontainers#793) chore: extract docker host calculation to an internal package (testcontainers#796) chore: run "go mod tidy" automatically when creating examples (testcontainers#794) chore: build images with backoff retries (testcontainers#792) fix: use right import package for compose in docs (testcontainers#791) chore(deps): bump google.golang.org/grpc from 1.52.1 to 1.52.3 in /examples (testcontainers#790) Add devcontainer file (testcontainers#765) chore: check dependabot dependencies weekly (testcontainers#789) chore(deps): bump google.golang.org/grpc from 1.52.0 to 1.52.1 in /examples (testcontainers#783) chore: support for titles in examples (testcontainers#775)
@mdelapenya I believe this is because the reaper container can be exposed by the Docker API before the reaper is ready to accept connections. I've opened the following PRs to address this:
|
What does this PR do?
Resolves #764 and also makes #258 (PR) obsolete.
As the issue describes, the Reaper container might exit if there's no connection for a longer time. For example when running multiple integration tests, some not using TestContainers. When that happens the next test will fail as Reaper is created as singleton but no connection can be created.
Why is it important?
Have reliable tests
Related issues