The Cedar repo was reset last week and we didn't pick up any changes afterwards. I think this is what happened: * repo is at revision X in m-c * reclone twig from m-c, so that X exists but isn't the tip * json-pushes returns {} for old polling request ?fromchange=X * that just looks like an idle repo to the poller, and we don't detect changes in the repo So perhaps the problem is the way that json-pushes behaves in that case. IIRC, the poller was requesting changes like this http://hg.mozilla.org/projects/cedar/json-pushes?full=1&fromchange=cdb90b48f19f and missing vlad's pushes bbceaac2d43a and 490ae06cda1c. Aki's fix was to disable polling cedar by adding it to this line http://hg.mozilla.org/build/buildbot-configs/file/47620d1d11a8/mozilla/scheduler_master.cfg#l16 then doing a reconfig, then reverting that.

All of the pushlog code tends to assume that nobody is monkeying with the repo.

Why didn't pushlog report Vlad's pushes?

Presumably because it was reset too, and had no record of rev cdb90b48f19f. For our purposes an error would be better than {}.

We used to get errors when requesting non-existent changesets.

Still an issue?

During triage today we confirmed that HgPoller needs some mechanism to know how to forget the rev it thinks is the current tip. Turns out we already have this in http://hg.mozilla.org/build/buildbotcustom/file/f947452130ae/changes/hgpoller.py#l252 I've verified there is a 500 response, with 'unknown revision' in the content, if you ask for a bogus revision when pushlog has at least one revision recorded. If it's empty because a twig was reset, or in my test a newly created a user repo, then you just get a 200 and '{}' back. Could we make it respond in the same way in the two cases ?

If the pushlog DB doesn't exist, the Query logic just short-circuits currently: http://hg.mozilla.org/hgcustom/pushlog/file/e99a36d3fd4a/pushlog-feed.py#l73 Presumably you get the 500 error for some other reason when the changeset is bad. I guess we can fix things to 500 error when querying for a changeset with an empty db, it just feels a little weird REST-wise.

I'm going to say this will be resolved by lastpushid and automation querying by startID.