Some exercise UUIDs are shared between tracks

[ee7]

Recall that configlet lint currently checks in track CI that every exercise UUID is:

• a valid version 4 UUID in the lowercase and hyphen-separated form
• unique within the track

However, it does not produce an error if the UUID exists on another track. That can happen when somebody copy-pastes data from another track when adding an exercise, but forgets to change the UUID.

As of 2023-03-23T13:40:00Z, there are 16 shared UUIDs. Each is shared by exactly two tracks.

Ordering by track, then exercise:

Tracks	Exercise	Exercise UUID in track config.json
abap, javascript	beer-song	6573f168-d8fc-4ccf-a864-1a61f432fae1
bqn, python	hello-world	f458c48a-4a05-4809-9168-8edd55179349
elixir, gleam	darts	a68113f8-92be-40e0-a97f-eb4239303ef5
elixir, gleam	freelancer-rates	fee79e03-1496-476f-964f-e60632cb13dc
elixir, gleam	raindrops	4522b139-6f0c-4172-a4fa-6a6adef33a9e
elixir, gleam	series	4a084cb7-335d-41f1-8148-5d3abbce8ab0
elm, gleam	pangram	a70503ba-f1f3-4583-9226-c3ada98e9500
fsharp, gleam	circular-buffer	b62f8574-9bac-4b95-a76c-f13789ae2663
fsharp, gleam	diamond	736a470f-412c-41fc-b92d-9bd59ef3bcce
fsharp, gleam	protein-translation	612395a5-238e-4be0-8ce0-4ac66f57056e
fsharp, gleam	rna-transcription	3a015501-58bf-427c-8c4c-2197321f4a34
fsharp, gleam	word-count	0c7a2f06-1e53-4043-9e1a-386e90e945b4
java, python	sgf-parsing	0d6325d1-c0a3-456e-9a92-cea0559e82ed
javascript, wasm	binary-search	7c569e5d-bb00-44b8-8adc-34253790c19b
javascript, wasm	triangle	ed3ca73a-a0f0-46b8-8013-8b6d20758c8f
sml, typescript	reverse-string	86d5a60a-fc44-443d-bc00-5c6265e736c4

Options:

1. Do not change the UUID on any track. And if shared exercise UUIDs do currently cause a significant problem on the backend, deal with it there.
2. For each shared UUID, change it on one track (probably the track that added it later).
3. For each shared UUID, change it on both tracks.
4. Wait until track CI performs Exercism-wide UUID checks, and only then do option 2 or 3.

A couple of years ago, we changed these duplicate UUIDs and these invalid UUIDs. When a UUID appeared on more than one track, we changed it on every track.

---

Note that even if configlet lint learns to check UUID uniqueness across all tracks, we cannot rely on it completely due to a possible race with our current repo architecture. We can still add a duplicate UUID if we, for example:

1. Create a PR on track A with UUID foo
2. Create a PR on track B with UUID foo
3. Merge the PR on one track
4. Merge the PR on the other track

That is, configlet lint will pass in each PR (and therefore not block merging) if its final run occurs before the other PR is merged. To address that, we'd need a cross-repo merge queue - not worth the complexity for this case alone. Hopefully at least one configlet lint check on main is guaranteed to fail, even if both PRs are merged at the same moment.

[BethanyG]

I'm for options 2 or 3. Feels like if we wait either for problems or for project-wide checks, we run the risk of forgetting about it. And then we'll just pile up more instances as time goes on.

[ee7]

@iHiD @ErikSchierboom Some questions:

• Does this issue cause any problems?
• Should we fix it?
• Should we make the website fail to sync and open an issue on the track when a UUID already exists on another track?

[ErikSchierboom]

Does this issue cause any problems?

I'm not sure. It might not because of the way we're usually matching on either slug or via foreign keys (which use a different field)

Should we fix it?

Probably. I think it would mean a concerted effort where just before merging we update the guid in the database

Should we make the website fail to sync and open an issue on the track when a UUID already exists on another track?

Yeah, that would be a good idea

[ee7]

Probably.

OK. Note that the number of shared UUIDs has doubled in the time since I created this issue. All from Gleam. I've updated the table in the first post.