The latest updates on your projects. Learn more about Vercel for Git ↗︎

This doesn't make sense to me. I'm confused why any of this needs to be sorted when in multiple runs (without touching turbo.json) we should still get consistent ordering.

To my knowledge we're not doing anything that inserts asynchronous behavior into the processing of these values.

@nathanhammond not everything was non-deterministic, but the test is to help ensure it stays that way. The non-determinism that we have is coming from the Set implementation. It's a map under the hood, and Go's map iteration is intentionally random, so when we convert back to a list, it's in a random order.

Ah, good catch on Set being the guilty party. It makes sense to provide no guarantees about map iteration order but is also an annoying footgun coming from a JavaScript background. (Added to my mental list of "fun" Go things.)

Also, a bit surprised that map iteration is random with the same values in the map from a single-threaded use. That implies to me it's an actively randomized iteration.

@nathanhammond as a bonus: serializing a map to a string is deterministic. They sort it in the String() implementation. The hashing we do relies on that, it's hashing the string representation of all the maps it finds.

actively randomized iteration

Yes, it is intentionally actively randomized

This calls for a 1.5.3. sigh