846249 - mozilla-inbound d74b3403dfe0 missing from pushlog database

Status: RESOLVED WONTFIX

(Developer Services :: Mercurial: hg.mozilla.org, defect)

Description

[Ed Morley [:emorley]]

Context:
Stock Mercurial doesn't have a concept of who/when changes were pushed to a repository, so ted created http://mercurial.selenic.com/wiki/MozillaPushlogExtension which stores this additional metadata in a sqlite DB; which has to be kept in sync with the repository. Many downstream consumers make use of the pushlog - eg: TBPL, Datazilla, ...

This inbound commit:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d74b3403dfe0

Is missing from the pushlog database:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=d74b3403dfe0

1) Can we manually add it back to the DB?
2) Why did this entry get omitted? Failure to commit that transaction to the DB? Person who pushed ctrl+C'd out at the wrong point?
3) How can we automate spotting this has happened again? Perhaps the pushlog extension can check that the last commit from the repo is in the pushlog DB, and deny subsequent pushes until it's corrected by hand?

Comment 1

[Ed Morley [:emorley]]

Note:
A commit missing from the pushlog effectively means it is invisible on TBPL - both the push/commit message & the build/test results on that push are not shown.

Comment 2

[Ed Morley [:emorley]]

Oleg, did you ctrl+c on the push in comment 0?

Comment 3

[Ed Morley [:emorley]]

Self-serve doesn't recognise it:
https://secure.pub.build.mozilla.org/buildapi/self-serve/mozilla-inbound/rev/d74b3403dfe0

Comment 4

[(not currently active) Ted Mielczarek]

I'm not really sure how the hook could fail to insert but still allow the push to succeed:
http://hg.mozilla.org/hgcustom/hghooks/file/tip/mozhghooks/pushlog.py

The code is structured so that the return value should only be set to 0 if the insert succeeds, and a return value of 1 should cause the push to be rejected by Mercurial.

Looking at the parent and child changesets of this changeset in the pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=8bc277012c6c
https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=49b4afb3ab2f

Shows their push IDs are sequential, so somehow this push really did fail to get recorded. :-/

Comment 5

[Ryan VanderMeulen [:RyanVM]]

I remember hitting this once with the ctrl+c mid-push situation.

Comment 6

[(not currently active) Ted Mielczarek]

We don't have a simple way to fix this, unfortunately, we'll probably have to resort to database surgery. Something like:
1) dump all the data for pushes with ID >= 23772 and their associated changesets
2) delete all those pushes and changesets
3) insert a push+changeset for this missing push
4) increment IDs for all the previously-dumped data, insert them

Comment 7

[[e-mail] (:bhearsum)]

It sounds like the acute issue is WFM or WONTFIX. If this bug needs to stay open it should probably be retitled for the systematic issue.

Comment 8

[Hal Wine [:hwine] use NI!]

Marking as WONTFIX, if we get further instances, we can figure out the pattern.