Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions java-dataplex/grpc-google-cloud-dataplex-v1/pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -46,4 +46,15 @@
<artifactId>guava</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>com.spotify.fmt</groupId>
<artifactId>fmt-maven-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
</plugins>
</build>
</project>
Original file line number Diff line number Diff line change
Expand Up @@ -124,6 +124,7 @@
.get(AttributeKey.stringKey(ObservabilityAttributes.SERVER_ADDRESS_ATTRIBUTE)))
.isEqualTo(SHOWCASE_SERVER_ADDRESS);

Thread.sleep(100);

Check warning on line 127 in sdk-platform-java/java-showcase/gapic-showcase/src/test/java/com/google/showcase/v1beta1/it/ITCompositeTracer.java

View check run for this annotation

SonarQubeCloud / [gapic-generator-java-root] SonarCloud Code Analysis

Remove this use of "Thread.sleep()".

See more on https://sonarcloud.io/project/issues?id=googleapis_google-cloud-java_showcase&issues=AZ2xj97yDZJsarjiHLR9&open=AZ2xj97yDZJsarjiHLR9&pullRequest=12880
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Using Thread.sleep() to handle asynchronous metrics collection is brittle and can lead to flaky tests. In a slow or resource-constrained CI environment, 100ms may not be sufficient, while in faster environments, it introduces unnecessary delays. A more robust approach is to use a polling mechanism, such as Awaitility, to wait for the metrics to be available with a reasonable timeout. This ensures the test proceeds as soon as the condition is met and is less sensitive to environment speed. Additionally, when testing for metric generation, it is acceptable to assert the exact number of metrics to ensure no unexpected metrics are produced.

References
  1. When testing for metric generation, it is acceptable to assert the exact number of metrics to ensure no unexpected metrics are produced.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with this in general, but we don't have Awaitility introduced yet. This PR is to unblock the current CI and it should be a separate effort to introduce Awaitility.

// Verify metric name and one basic attribute server.address
Collection<MetricData> actualMetrics = metricReader.collectAllMetrics();

Expand Down
Loading