[Bug] Incorrect Assumption on HashSet Iteration Order in PoliciesDataTest.propertyAdmin" #24870
Description
Search before reporting
- I searched in the issues and found nothing similar.
Read release policy
- I understand that unsupported versions don't get bug fixes. I will attempt to reproduce the issue on a supported version of Pulsar client and Pulsar broker.
User environment
Broker version: 4.2.0-SNAPSHOT
Broker Operating system and hardware type: Linux x86_64 GNU/Linux
Broker Java version: 17.0.16
Issue Description
The below test performed an assertion that incorrectly assumed the order of the HashSet data that was utilized in the formation of one of the arrays. No guarantees are made to the iteration order of the set or that this order will remain constant over time. As a result, the ordering can change due to different environments producing the contents in different orders despite the logical contents being the same.
org.apache.pulsar.common.policies.data.PoliciesDataTest.propertyAdmin
I discovered the problem with the NonDex tool. NonDex systematically detects incorrect tests that rely on non-deterministic behaviors in Java APIs—like assuming order of name/value pairs in json files — by exploring all specification-allowed outcomes. It does this by instrumenting undetermined APIs and randomizing the returned order/behavior within what the spec allows. Failures it exposes reliably indicate flawed assumptions in order that were never promised and should be fixed.
Error messages
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.pulsar.common.policies.data.PoliciesDataTest
[ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 2.909 s <<< FAILURE! -- in org.apache.pulsar.common.policies.data.PoliciesDataTest
[ERROR] org.apache.pulsar.common.policies.data.PoliciesDataTest.propertyAdmin -- Time elapsed: 0.005 s <<< FAILURE!
java.lang.AssertionError: Lists differ at element [0]: role1 != role2 expected [role1] but found [role2]
at org.testng.Assert.fail(Assert.java:110)
at org.testng.Assert.failNotEquals(Assert.java:1577)
at org.testng.Assert.assertEqualsImpl(Assert.java:149)
at org.testng.Assert.assertEquals(Assert.java:1643)
at org.testng.Assert.assertEquals(Assert.java:1605)
at org.apache.pulsar.common.policies.data.PoliciesDataTest.propertyAdmin(PoliciesDataTest.java:74)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:569)
at org.testng.internal.invokers.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:139)
at org.testng.internal.invokers.InvokeMethodRunnable.runOne(InvokeMethodRunnable.java:47)
at org.testng.internal.invokers.InvokeMethodRunnable.call(InvokeMethodRunnable.java:76)
at org.testng.internal.invokers.InvokeMethodRunnable.call(InvokeMethodRunnable.java:11)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:840)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] org.apache.pulsar.common.policies.data.PoliciesDataTest.propertyAdmin
[INFO] Run 1: PASS
[ERROR] Run 2: PoliciesDataTest.propertyAdmin:74 Lists differ at element [0]: role1 != role2 expected [role1] but found [role2]
[INFO]
[INFO]
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
Reproducing the issue
You can replicate the problem with the NonDex tool command:
mvn -pl pulsar-common -Dtest=org.apache.pulsar.common.policies.data.PoliciesDataTest#propertyAdmin -DnondexSeed=1554838 edu.illinois:nondex-maven-plugin:2.2.1:nondex
Additional information
No response
Are you willing to submit a PR?
- I'm willing to submit a PR!