Bug 1058808 provided a self-serve solution for resetting the pushlog cache for a repo, so we can un-jam ingestion after a repository (and its pushlog) are reset. This does work, however requires manual intervention, so: 1) It's easy for dev/staging to be forgotten for this process, and so they are not ingesting data for all repos. 2) When the cache is cleared, we fallback to using /json-pushes/ with no params, which returns the last 24 hours of pushes. However if it has been greater than 24 hours since the pushlog was reset, we'll permanently lose the older pushes. A better solution that will fix #1 + #2 above, as well as mean people don't have to manually do the reset, would be to automatically invalidate cache were the current push ID now invalid. Detecting this currently isn't possible, since an invalid startID returns 200 and the same (empty) json response as the "no new pushes since that ID" case. Once bug 1065771 is fixed, we can add handling to invalidate the cache if we get a 404 response (or whatever is chosen there).

The fix in bug 1071577 (https://github.com/mozilla/treeherder-service/commit/ba881e203092d6f016725ddf92eefb810db577cd) means that there is no cached value any more, so there is nothing left to document.

(In reply to Ed Morley [:edmorley] from comment #1) > The fix in bug 1071577 > (https://github.com/mozilla/treeherder-service/commit/ > ba881e203092d6f016725ddf92eefb810db577cd) means that there is no cached > value any more, so there is nothing left to document. Since then, we've moved back to an approach that uses the cache, but now uses &fromchange=rev. Since the pushlog correctly returns 404 when using fromchange (unlike startID), the approach given in comment 0 of this bug was then possible - and so was implemented in https://github.com/mozilla/treeherder-service/commit/cb3d46df361ce7d03acdbde7d0d8da81aab711e9 (bug 1072291).