test-issue-226-hash-stats-sort-e2e.js fails intermittently in CI with not the server order. It failed on attempts 1 and 2 of run 37293748200 for #252, then passed on attempt 3. The PR it ran on changes only an unrelated E2E file.
Cause
computeAnalyticsHashSizes in cmd/server/store.go (master d05b0db5, around lines 9072–9093) builds multiByteNodes by ranging over the byNode map. It then sorts on packets only:
sort.Slice(multiByteNodes, func(i, j int) bool {
return multiByteNodes[i]["packets"].(int) > multiByteNodes[j]["packets"].(int)
})Go map iteration order is random, and sort.Slice is not stable. Nodes with equal packet counts therefore come out in a different order on each recompute of the analytics cache.
The test reads serverOrder from the API once (line ~135). It then compares the rows of later page loads against it (lines ~146 and ~211). If the cache recomputes in between and there are ties, the comparison fails, although nothing is wrong with the page.
This is also a small UX issue: the default ("server order") adopters table can reshuffle tied rows between visits.
Expected
- Server: a deterministic order. Sort by
packets descending, then by pubkey ascending as a tie-breaker. A Go unit test with tied counts should give the same order across repeated computes.
- Test (optional extra hardening): the E2E takes the expected order from the same
/api/analytics/hash-sizes response the page rendered, or asserts only on rows with distinct packet counts.
- Check the other analytics lists built from map iteration and sorted on a single key, and fix them in the same way if they are shown in "server order".
Evidence
test-issue-226-hash-stats-sort-e2e.jsfails intermittently in CI withnot the server order. It failed on attempts 1 and 2 of run 37293748200 for #252, then passed on attempt 3. The PR it ran on changes only an unrelated E2E file.Cause
computeAnalyticsHashSizesincmd/server/store.go(masterd05b0db5, around lines 9072–9093) buildsmultiByteNodesby ranging over thebyNodemap. It then sorts onpacketsonly:Go map iteration order is random, and
sort.Sliceis not stable. Nodes with equal packet counts therefore come out in a different order on each recompute of the analytics cache.The test reads
serverOrderfrom the API once (line ~135). It then compares the rows of later page loads against it (lines ~146 and ~211). If the cache recomputes in between and there are ties, the comparison fails, although nothing is wrong with the page.This is also a small UX issue: the default ("server order") adopters table can reshuffle tied rows between visits.
Expected
packetsdescending, then bypubkeyascending as a tie-breaker. A Go unit test with tied counts should give the same order across repeated computes./api/analytics/hash-sizesresponse the page rendered, or asserts only on rows with distinct packet counts.Evidence
d05b0db5. The fix has not been tested yet.