Hiccup in 2024-09-23 triage: curl from parent had only prefix of data

The usual triage process is to issue a curl command like curl "https://perf.rust-lang.org/perf/triage?start=$PARENT", where $PARENT is found by looking at the end commit for the previous week's triage.

However, back on 2024-09-23, that methodology yielded a subset of the expected data.

In particular, the result from doing:

curl "https://perf.rust-lang.org/perf/triage?start=170d6cb845c8c3f0dcec5cdd4210df9ecf990244"

is a report that covers the commit range: Revision range: 170d6cb8..749f80ab, a range covering just 2024-09-16 through 2024-09-19.

Luckily, @Kobzol pointed this out to me (I was driving 2024-09-23 triage) and so I ended up working around the issue (by manually looking at the history, determining that commit 506f22b4663f3e756e1e6a4f66c6309fdc00819c looked like the next merge from bors, using that latter commit as the basis for a second curl query, and then manually combining the two reports into one semi-unified report).

But it would be good to understand why this happened, and try to prevent it.

Start by reproducing the curl request to perf.rust-lang.org/perf/triage with parent commit 170d6cb845c8c3f0dcec5cdd4210df9ecf990244 and compare it with the manually identified 506f22b4663f3e756e1e6a4f66c6309fdc00819c. Trace the triage endpoint's commit-range selection and determine why the report stops at 749f80ab; done means the cause is documented and the process or endpoint prevents truncated reports.