issues 1566, 1567, 1568 and others are misplaced in the index of issues

[gschare]

Important note: even after redownloading and regenerating, the numbers of issues which were misplaced were consistent. There is likely actually two different things going on with different causes:

• certain issues misplaced but still in index (e.g. 1566-1568)
• certain issues gone entirely (e.g. issue 1587)

A strong theory is implied by the fact that 1566-1568 were transferred from a different repo into m-k-manuscript-data, while 1587 was transferred out to a different repo.

Per Terry, possibilities for the source of the bug:

• mistake in API request, i.e. getting things in the wrong order
• API is putting things in the wrong order either purposefully or as a bug in itself
  • if purposeful, this could be because the JSON is sorted not on date of creation but on something else. More likely, though, given the evidence above, the API is in fact sorting correctly on date of creation, because issues which were transferred between repos will be given a new number to fit into the new repo but their date of creation will remain the same as before.
• bug in Haskell processing
  • we do not sort them; we just take the order given by the JSON from the update.sh script; this would likely fix the symptom

I'm almost entirely convinced it is a matter of transferring issues between repos and only that. In light of that, I am not strongly compelled to programmatically confirm this is the case. Because we want the index to be sorted by number, not creation date (confirm?) we may simply sort by number in the Haskell processing step.

[gschare]

Later on, we can add sort options to the index page so that the user can see issues sorted by creation date, alphabetical, number, modification date, etc.