Comment 10 for bug 534066

Ok, there's clearly a problem with the ETag generation. Fixing it will not fill fix all our 412 errors (eg. bug 336866), but it's a start.

task_age changes every second, which means the generated ETag changes every second, which means all PATCH requests will result in 412 errors. Clearly changes to task_age should not affect the generated ETag.

HOWEVER, by the same token, I suggest that task_age is useless and should not be published. If you are using launchpadlib you have no way of knowing how old your representation of a bugtask is. Maybe it's an hour old, maybe it's a day old. What's the right value for task_age? You don't know, and there's no way to find out. Changes to task_age don't affect the ETag, so you'll never be able to convince launchpadlib that it has an out-of-date representation. So long as nothing but task_age has changed, Launchpad will tell your client that it already has the most up-to-date representation.

task_age isn't even necessary, since you can subtract date_created from the current time. If I had to guessed I'd say it was published to make it easier to write some Ajax code, but it's causing more problems than it's worth, and I'm not confident that an Ajax application won't have the same problem with out-of-date values as launchpadlib. I suggest we get rid of the field.

That said, it's likely there are more fields that are screwing up the ETags in this way, and not all of them can simply be removed. What are the other candidates? And do you agree about getting rid of task_age?