You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
nadove-ucsc opened this issue
Jul 23, 2024
· 3 comments
Labels
--[priority] Lowbug[type] A defect preventing use of the system as specifieddebt[type] A defect incurring continued engineering costneeds info[process] Resolution requires more informationorange[process] Done by the Azul teamtest[subject] Unit and integration test code
While working on #6122, we had difficulty asserting the contents of the verbatim PFB manifest due to inconsistencies in the ordering of the replicas. The order appeared stable on a personal deployment, but changed when pushing to GitHub. Our investigation revealed that the shard count affected the order of the replicas in the index, but patching the shard count to a consistent value (1) did not result in a consistent order.
Currently, our workaround is to sort the manifests before comparing the expected and observed values.
The text was updated successfully, but these errors were encountered:
It remains undetermined whether the inconsistency is due to the order in which the replicas are written to the index, or whether it arises when reading them from the index.
hannes-ucsc
added
-
[priority] Medium
bug
[type] A defect preventing use of the system as specified
test
[subject] Unit and integration test code
debt
[type] A defect incurring continued engineering cost
--
[priority] Low
and removed
-
[priority] Medium
labels
Sep 4, 2024
--[priority] Lowbug[type] A defect preventing use of the system as specifieddebt[type] A defect incurring continued engineering costneeds info[process] Resolution requires more informationorange[process] Done by the Azul teamtest[subject] Unit and integration test code
While working on #6122, we had difficulty asserting the contents of the verbatim PFB manifest due to inconsistencies in the ordering of the replicas. The order appeared stable on a personal deployment, but changed when pushing to GitHub. Our investigation revealed that the shard count affected the order of the replicas in the index, but patching the shard count to a consistent value (1) did not result in a consistent order.
Currently, our workaround is to sort the manifests before comparing the expected and observed values.
The text was updated successfully, but these errors were encountered: