Copilot commented on code in PR #11168:
URL: https://github.com/apache/gravitino/pull/11168#discussion_r3272830845
##########
iceberg/iceberg-rest-server/src/test/java/org/apache/gravitino/iceberg/service/rest/TestIcebergNamespaceOperations.java:
##########
@@ -183,6 +183,13 @@ void testDropNamespace() {
verifyCreateNamespaceSucc(Namespace.of("drop_foo3", "a"));
verifyDropNamespaceFail(404, Namespace.of("drop_foo3", "b"));
verifyDropNamespaceSucc(Namespace.of("drop_foo3", "a"));
+
+ // drop non-empty namespace should return 409 Conflict per Iceberg REST
spec
+ String uniqueSuffix = String.valueOf(System.nanoTime());
+ Namespace nonEmptyNs = Namespace.of("drop_nonempty_foo_" + uniqueSuffix);
+ verifyCreateNamespaceSucc(nonEmptyNs);
+ verifyRegisterTableSucc("drop_nonempty_table_" + uniqueSuffix, nonEmptyNs);
+ verifyDropNamespaceFail(409, nonEmptyNs);
Review Comment:
This test creates a namespace and registers a table but doesn’t clean them
up. If the REST server or catalog state is shared across tests (or reused
across test methods), this can cause cross-test interference and make failures
order-dependent. Consider adding a `try/finally` (or equivalent teardown) to
drop the table and namespace after the assertion(s), even when the
drop-namespace call is expected to fail.
##########
iceberg/iceberg-rest-server/src/test/java/org/apache/gravitino/iceberg/service/rest/TestIcebergNamespaceOperations.java:
##########
@@ -183,6 +183,13 @@ void testDropNamespace() {
verifyCreateNamespaceSucc(Namespace.of("drop_foo3", "a"));
verifyDropNamespaceFail(404, Namespace.of("drop_foo3", "b"));
verifyDropNamespaceSucc(Namespace.of("drop_foo3", "a"));
+
+ // drop non-empty namespace should return 409 Conflict per Iceberg REST
spec
+ String uniqueSuffix = String.valueOf(System.nanoTime());
+ Namespace nonEmptyNs = Namespace.of("drop_nonempty_foo_" + uniqueSuffix);
+ verifyCreateNamespaceSucc(nonEmptyNs);
+ verifyRegisterTableSucc("drop_nonempty_table_" + uniqueSuffix, nonEmptyNs);
Review Comment:
`System.nanoTime()` is not ideal for generating unique test identifiers
because it makes failures harder to reproduce/debug and can behave unexpectedly
across environments. Prefer a deterministic-but-unique approach for tests
(e.g., a UUID or a JUnit-provided unique test name) so the intent is explicit
and the ID format is stable.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
