[pushlog] json-pushes should also return an unknown revision error when pushlog db is empty

RESOLVED DUPLICATE of bug 1104374

Status

Developer Services
Mercurial: hg.mozilla.org
P3
normal
RESOLVED DUPLICATE of bug 1104374
8 years ago
3 years ago

People

(Reporter: nthomas, Unassigned)

Tracking

Details

(Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1430] )

(Reporter)

Description

8 years ago
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.

Updated

8 years ago
Duplicate of this bug: 603445
Why didn't pushlog report Vlad's pushes?
(Reporter)

Comment 4

8 years ago
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.

Comment 6

7 years ago
Still an issue?
Component: Release Engineering → Release Engineering: Automation
QA Contact: release → catlee
(Reporter)

Comment 7

6 years ago
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 ?
Component: Release Engineering: Automation → Hg: Customizations
QA Contact: catlee → hg.customizations
Summary: HgPoller doesn't detect changes when twig is recloned and old tip still exists → [pushlog] json-pushes should also return an unknown revision error when pushlog db is empty
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.
(Assignee)

Updated

5 years ago
Product: mozilla.org → Release Engineering
(Assignee)

Updated

3 years ago
Product: Release Engineering → Developer Services

Updated

3 years ago
Whiteboard: [kanban:engops:https://kanbanize.com/ctrl_board/6/246]

Updated

3 years ago
Whiteboard: [kanban:engops:https://kanbanize.com/ctrl_board/6/246] [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1417] [kanban:engops:https://kanbanize.com/ctrl_board/6/246] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1417] [kanban:engops:https://kanbanize.com/ctrl_board/6/246] [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1418] [kanban:engops:https://kanbanize.com/ctrl_board/6/246]

Updated

3 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1418] [kanban:engops:https://kanbanize.com/ctrl_board/6/246] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1424] [kanban:engops:https://kanbanize.com/ctrl_board/6/246]

Updated

3 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1424] [kanban:engops:https://kanbanize.com/ctrl_board/6/246] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1427] [kanban:engops:https://kanbanize.com/ctrl_board/6/246]

Updated

3 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1427] [kanban:engops:https://kanbanize.com/ctrl_board/6/246] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1430] [kanban:engops:https://kanbanize.com/ctrl_board/6/246]
(Assignee)

Updated

3 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1430] [kanban:engops:https://kanbanize.com/ctrl_board/6/246] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1430]

Comment 9

3 years ago
I'm going to say this will be resolved by lastpushid and automation querying by startID.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1104374
You need to log in before you can comment on or make changes to this bug.