ValueError OOPS on codehosting

Bug #701953 reported by Ursula Junque on 2011-01-12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Jelmer Vernooij
Launchpad itself

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
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/
    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.

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.

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…).

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.

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
William Grant (wgrant) wrote :

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

John A Meinel (jameinel) wrote :

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.

Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla -


William Grant (wgrant) on 2012-10-22
tags: added: codehosting-ssh
Steve Kowalik (stevenk) wrote :

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

Steve Kowalik (stevenk) wrote :

Since my OOPSes keep getting pruned. OOPS-a2dd08ba675ae84449f39ddabbe02220

  Module, line 358, in _call_converting_errors
    return callable(*args, **kwargs)
  Module, line 143, in execute
  Module, line 76, in do
    return self.do_repository_request(self._repository, *args)
  Module, line 149, in do_repository_request
    return self.do_readlocked_repository_request(repository, *args)
  Module, 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) on 2012-12-11
tags: added: bzr
tags: removed: bzr
Jelmer Vernooij (jelmer) on 2017-11-09
tags: added: check-for-breezy
Jelmer Vernooij (jelmer) on 2019-02-15
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) on 2019-02-15
Changed in brz:
status: Triaged → Fix Committed
Jelmer Vernooij (jelmer) on 2019-03-10
Changed in brz:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers