lp_save now gives PreconditionFailed if unchanged

Bug #415943 reported by James Westby
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Invalid
Undecided
Unassigned

Bug Description

Hi,

lp.load("https://api.edge.launchpad.net/beta/~ubuntu-branches/ubuntu/karmic/libdatetime-format-iso8601-perl/karmic").lp_save()

fails more than 50% of the time. This is causing all package imports to fail
currently.

Thanks,

James

Revision history for this message
James Westby (james-w) wrote : Re: branch.lp_save() often give PreconditionFailed

This appeared to start at 2009-08-19 08:44:38.

Thanks,

James

summary: - branch.lp_save() always give PreconditionFailed
+ branch.lp_save() often give PreconditionFailed
Revision history for this message
James Westby (james-w) wrote :

The actual code isn't just saving unchanged, it's modifying the
lifecycle_status and saving that, though it will leave the
status unchanged in some circumstances. It appears as though
whatever changed is just that it now gives errors if you save
unchanged, but lets through real changes.

Thanks,

James

Revision history for this message
James Westby (james-w) wrote :

Confirmed that this goes beyond branches using lp.me.lp_save().

Unable to reproduce on launchpad.dev with r9155 of ~launchpad-pqm/launchpad/devel.

Thanks,

James

summary: - branch.lp_save() often give PreconditionFailed
+ branch.lp_save() now gives PreconditionFailed if unchanged
summary: - branch.lp_save() now gives PreconditionFailed if unchanged
+ lp_save now gives PreconditionFailed if unchanged
affects: launchpad-code → launchpad-foundations
Revision history for this message
James Westby (james-w) wrote :

This has disappeared. Leonard suggests it was a deployment issue related to
a cache or similar.

Thanks,

James

Changed in launchpad-foundations:
status: New → Incomplete
Revision history for this message
Leonard Richardson (leonardr) wrote :

It looks like this problem showed up because edge was in an inconsistent state. Some of edge's app servers were on version N of Launchpad, and some were on version N-1.

The ETag generated for a resource changes whenever the version number changes. So if GET requests go to a version N-1 appserver and PATCH requests go to a version N appserver, the PATCH request will fail, even though subsequent GETs will show nothing wrong with the ETag. This describes the problem exactly.

The problem disappeared when the LOSAs upgraded the app servers so that they were all running version N. Therefore I've marked this bug Invalid.

Changed in launchpad-foundations:
status: Incomplete → Invalid
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.