ValueError OOPS on codehosting

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.

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.

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.

@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'.

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

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

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

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.