l-unclaimed is a list which is populated with SHA1 IDs, when a job is ran the SHA1 ID should be removed from l-unclaimed and added to the queue's z-claimed sorted listed. This happens most of the time except in job de-duplication circumstances - where only one ID is removed from l-unclaimed.

This means when we pop the ID in future from l-unclaimed, there is no associated h-data entry - therefore the script assumes this is a race condition and re-pushes the ID back to l-unclaimed.

As the h-data was removed once it was established it was a duplicate job, we no longer know about the jobs existence. MediaWiki doesn't have a problem with this - however our Grafana statistics do (quite rightly!).

We should introduce a periodic task that checks l-unclaimed IDs always have an associated h-data entry.