fix(server): sort module cache destinations for stable dashboard ordering

What changed

The Module Cache view in a build/test run dashboard now renders each target’s Destinations in a deterministic, sorted order. Both the visible Destinations row and the “Copy as JSON” export sort the destinations by their raw value before display.

Why

Destinations are stored as an unordered ClickHouse Array(LowCardinality(String)), so the dashboard previously showed them in whatever order the CLI happened to send. The same module then appeared with a different ordering across builds, e.g.:

• iPad, iPhone, Mac with iPad design
• Mac with iPad design, iPhone, iPad

This reads as if the target changed between builds when it did not, which is confusing for users investigating cache misses.

Important: this is cosmetic only

The cache key is unaffected. The CLI already sorts destinations before hashing (TargetContentHasher does .map(\.rawValue).sorted()), which is why the module hash stays identical across builds regardless of display order. So this change does not alter anyone’s cache hit/miss outcome; it only makes the displayed order stable and consistent.

Sorting by the raw enum value (ipad < iphone < mac_with_ipad_design) keeps the display aligned with the CLI’s canonical hash order. The JSON export is sorted too, so the visible list and the copied JSON never disagree.

Validation

Added a subhashes_list/1 component test that renders the same destination set in two different input orders and asserts the output is identical and sorted (iPad, iPhone, Mac with iPad design).

mix test test/tuist_web/live/module_cache_live_test.exs
# 2 tests, 0 failures

How to test locally

1. Open a build run’s Module Cache tab for a target that has multiple destinations.
2. Confirm the Destinations row is shown in a stable, sorted order and matches across different builds of the same module.
3. Use “Copy as JSON” and confirm the destinations array is sorted the same way.

No GitHub comments yet.