Changes made through the API (via javascript) aren't blacklisting the Slave DBs

Bug #447453 reported by Paul Hummer on 2009-10-09
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Stuart Bishop

Bug Description

So, the dupe finder didn't find this bug, but I was told there was one. If there is, feel free to mark this as a dupe.

The code team has increasingly been finding that javascript "appears" to be broken on update. See bugs #426141 and #447353 - Basically, what's happening here is that the change is successful through the API, the javascript requests a page fragment, and that page fragment request hits the slave db, which hasn't been updated yet, and so is missing the new changes. This results in what appears to be a failed attempt, even though the LP client succeeded.

From a conversation with Francis about this, he said:
<flacoste> ah, i know what is happening
<flacoste> API requests use the MasterStore policy
<flacoste> which doesn't update the last_write of the session

Related branches

Gary Poster (gary) on 2009-10-09
Changed in launchpad-foundations:
importance: Undecided → High
status: New → Triaged
assignee: nobody → Stuart Bishop (stub)
Stuart Bishop (stub) wrote :

I'll see if I can make API requests update the last_write value in the session if there is a session cookie. Hopefully, the API requests are being sent with a session cookie (if not, we need to fix it so they are).

Michael Hudson-Doyle (mwhudson) wrote :

I'm pretty sure API requests from Javascript have a session cookie -- it's how they're authenticated!

Stuart Bishop (stub) on 2009-10-12
Changed in launchpad-foundations:
status: Triaged → In Progress
milestone: none → 3.1.10
Changed in launchpad-foundations:
status: In Progress → Fix Committed
Changed in launchpad-foundations:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers