flaky: #226 Hash Stats adopters sort E2E — server sorts multiByteNodes on packets only, ties come out in random order #256

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

• [K] CI logs of run 37293748200, as reported on test(packets): make the Details advert-link E2E independent of fixture age (#244) #252.
• [A] Code read on master d05b0db5. The fix has not been tested yet.