-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fixed flaky test for mongo client #6924
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
base: main
Are you sure you want to change the base?
Fixed flaky test for mongo client #6924
Conversation
|
|
||
| commandThreadMap.put("insert", | ||
| new Thread(() -> mongo.getDatabase("test") | ||
| new Thread(() -> requireNonNull(mongo).getDatabase("test") |
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.
Are these requireNonNull needed? Since it is asserted to not be null earlier, I would expect it shouldn't be needed.
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 thought so as well, but, because the field (now nullable) is used in the lambda, we still need the null checks.
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.
@shakuzen is it ugly?
We can have the mongo client as a local variable in each test instead of keeping it as a nullable class field to get rid of this.
But then we won't be able to use @AfterEach to close the clients, and we'll use try with resources everywhere
| .addClusterListener(new ClusterListener() { | ||
| @Override | ||
| public void clusterOpening(ClusterOpeningEvent event) { | ||
| clusterId.set(event.getClusterId().getValue()); |
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 think we don't want this to end up in the documentation snippet, but since it was there before, this isn't changing anything. We can tackle getting that out of the documentation in another PR.
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 tried removing it from the docs by adding an extra tag // tag::setup_2[] , but I couldn't get the docs to build locally and didn't want to risk breaking the indentation.
If we end up creating a separate issue for the docs, it might be worth adding something like a docker-compose to make local doc building easier. (if it works - I'm not familiar with antora). - what do you think?
for eg, Testcontainers has a setup like this for mkdocs:
https://github.com/testcontainers/testcontainers-java/blob/main/docker-compose.yml
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.
Did ./gradlew antora not work for you? What was the error?
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.
Sorry for the late reply! I had some time to look into it again today, and I've got it working.
There were a few different issues, for eg, for some reason, building the docs module was not using the project version for micrometer-observation. So, I was getting compilation errors because of some new classes used in ObservationHandlerTests.java. Then, I had some issues with the symbolic links in here.
But it worked in the end, and I split the tag into two. Therefore, that whole part with
ClusterSettings > ClusterListener > ClusterId should no longer show up in the documentation
Closes micrometer-metricsgh-4602 Signed-off-by: Emanuel Trandafir <emanueltrandafir1993@gmail.com>
38b051b to
b064a22
Compare
Closes gh-4602