ValueError OOPS on codehosting

Bug #701953 reported by Ursula Junque
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Low
Unassigned
Breezy
Fix Released
High
Jelmer Vernooij
Launchpad itself
Triaged
High
Unassigned

Bug Description

As seen on OOPS-1833BZR102411 and OOPS-1833BZR183131:
  ValueError: requested revno (2152) is later than given known revno (2151)

Related branches

Changed in launchpad:
status: New → Triaged
importance: Undecided → Critical
Revision history for this message
Benji York (benji) wrote :

I can't figure out how to reproduce these errors.

At first I thought that these errors weren't occurring any more, but
that's because the OOPS ID changes with the varying error message (the
revnos are different).

To see recent instances of the error log into devpad and grep for them:

    cd /srv/launchpad.net-logs/scripts/crowberry/codehosting-oopses
    grep 'is later than given known revno' **/*

I'm adding Bazaar to this bug. I'm not certain it is pertinent, but I
think so.

Revision history for this message
William Grant (wgrant) wrote :

IIRC I was able to reproduce the OOPS by just trying to branch a revno greater than the latest. That should cause a normal user error, but instead logs an OOPS.

Revision history for this message
Andrew Bennetts (spiv) wrote :

Note that legitimate bzr operations (most obviously 'push --overwrite' of an uncommit, but there are others) can cause a previous valid revno to no longer exist. So there will be cases where Launchpad offers a link to see revision number X, and then by the time the user follows that link the revision numbered X no longer exists. I doubt we can do better than 404 (perhaps with a helpful link to branch itself, which probably still does exist, although of course branches can be deleted!)

I *think* this may be a duplicate of a older bug report, but I might be misremembering.

Setting the append_revisions_only flag on a branch (which might become the default bzr behaviour for new branches one day?) would prevent this situation (until the user unsets the flag…).

Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 701953] Re: ValueError OOPS on codehosting

I concur with Andrew this should just be a 404, and then if possible
handled by the general approach of warning on 404s only when the
referrer is itself a Launchpad page.

Revision history for this message
John A Meinel (jameinel) wrote :

@wgrant do you mean doing "bzr branch -r X lp:a-branch" where X is greater than the tip revision of a-branch?

I agree that we can trigger this, but it still seems a bit strange. "Branch.get_rev_id()" seems to be pretty rare. I would certainly argue that we should avoid it as much as possible.

Is it possible to figure out what is actually triggering this and fix it?

I think it is reasonable to change the api to not raise an AssertionError in this case (it makes sense at the Repository level, but at the Branch level it hides the 'known_pair' from the user.)

I'm not really worried about someone doing "bzr branch -r 10001" when there are only 10000 revisions. Unless this is something like a cron script that is trying to poll for 'newer' revisions by manually setting the target revision to something 'newer'.

We could possibly just return the 'history-incomplete' value, since from what I can see, the bzr client only trusts the response if it gets 'ok'.

Changed in bzr:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
William Grant (wgrant) wrote :

John, the OOPSes show that someone is repeatedly and consistently asking for latestrevno+1 on a particular branch.

Revision history for this message
John A Meinel (jameinel) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/7/2011 9:53 AM, William Grant wrote:
> John, the OOPSes show that someone is repeatedly and consistently
> asking for latestrevno+1 on a particular branch.
>

Can you give details about what branch? Since that could give some
strong hints as to why.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5AA3kACgkQJdeBCYSNAAOfHwCdHvqgeHe5hMbII52dHtH6NZ2i
X1QAoIUcBKg95PnXvTzhbSb7mYgIROWR
=b0Yj
-----END PGP SIGNATURE-----

William Grant (wgrant)
tags: added: codehosting-ssh
Revision history for this message
Steve Kowalik (stevenk) wrote :

OOPS-6b69a23fa84d148d50abafe87a602ddf and OOPS-bc16db930edc384f068b386893ef4d0a are modern OOPSes.

Revision history for this message
Steve Kowalik (stevenk) wrote :

Since my OOPSes keep getting pruned. OOPS-a2dd08ba675ae84449f39ddabbe02220

  Module bzrlib.smart.request, line 358, in _call_converting_errors
    return callable(*args, **kwargs)
  Module bzrlib.smart.request, line 143, in execute
    return self.do(*args)
  Module bzrlib.smart.repository, line 76, in do
    return self.do_repository_request(self._repository, *args)
  Module bzrlib.smart.repository, line 149, in do_repository_request
    return self.do_readlocked_repository_request(repository, *args)
  Module bzrlib.smart.repository, line 329, in do_readlocked_repository_request
    found_flag, result = repository.get_rev_id_for_revno(revno, known_pair)
  Module bzrlib.repository, line 963, in get_rev_id_for_revno
    % (revno, known_revno))
ValueError: requested revno (302) is later than given known revno (170)

I guess the fix is to change bzrlib.repository's get_rev_id_for_revno to not raise a ValueError, but assume tip, which it obviously knows.

Curtis Hovey (sinzui)
tags: added: bzr
tags: removed: bzr
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
Jelmer Vernooij (jelmer)
tags: removed: check-for-breezy
Changed in brz:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Jelmer Vernooij (jelmer)
milestone: none → 3.0.0
Jelmer Vernooij (jelmer)
Changed in brz:
status: Triaged → Fix Committed
Jelmer Vernooij (jelmer)
Changed in brz:
status: Fix Committed → Fix Released
Colin Watson (cjwatson)
Changed in launchpad:
importance: Critical → High
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.