[ 
https://issues.apache.org/jira/browse/GEODE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donal Evans reassigned GEODE-10011:
-----------------------------------

    Assignee: Donal Evans

> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
>  is flaky
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-10011
>                 URL: https://issues.apache.org/jira/browse/GEODE-10011
>             Project: Geode
>          Issue Type: Bug
>          Components: redis
>    Affects Versions: 1.15.0, 1.16.0
>            Reporter: Donal Evans
>            Assignee: Donal Evans
>            Priority: Major
>
> {noformat}
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest > 
> scanWithNoModificationsDoesNotReturnDuplicates FAILED
>     java.lang.AssertionError: Property named 
> 'scanWithNoModificationsDoesNotReturnDuplicates' failed (
>     Expected size: 2 but was: 4 in:
>     [176, 55, 176, 55]):
>     With arguments: [[176, 55]]
>     Original failure message: 
>     Expected size: 2 but was: 4 in:
>     [55, 202, 55, 202]
>     First arguments found to also provoke a failure: [[55, 202]]
>     Seeds for reproduction: [5487908098719980972]
>         at 
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
>         Caused by:
>         java.lang.AssertionError: 
>         Expected size: 2 but was: 4 in:
>         [55, 202, 55, 202]
>             at 
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
> This failure is due to the test assuming that more than one scan is necessary 
> to scan the entire set, but for small set sizes (the set in the failure above 
> only has 2 members) it's possible that the first scan will return all 
> elements and a cursor value of 0, meaning that the second scan will also 
> return all elements, leading to duplicate elements in the result.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to