Comment 5 for bug 637323

Leonard Richardson (leonardr) wrote :

I see. Right now the ETag change whenever the code revision number changes. We can make it so that the "revision number" is a number we control and only increment when we actually change the web service. That will reduce this problem, but it won't totally eliminate it, and it'll mean that every Launchpad developer has to remember something extra.

We have a plan to freeze old versions of the web service (eg. "beta" and "1.0"; currently backward-compatible changes bleed through to earlier versions because it's easier than making sure they don't). Once we do this, we could associate a revision number with each version of the web service. Since the frozen versions would change very very rarely, you would pretty much never get this error as long as you were using a frozen version. You would get it more often if you were using devel,

But there's no way to totally get rid of this problem, because in the limiting case it is the correct behavior. If you get data from revision n of the web service, and then modify it and send your modification to be processed by revision n+k, the web service _should_ reject your request. It can't be expected to handle that request correctly, because it relied on assumptions that are no longer valid. It doesn't matter whether your two requests are separated by three months, across several Launchpad rollouts, or by a few seconds during a rollout. And of course if you get data from revision n+k and send it in to be processed by revision n, there's absolutely no hope.