Changes made through the API (via javascript) aren't blacklisting the Slave DBs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
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
- Abel Deuring (community): Approve (code)
- Aaron Bentley (community): Approve
-
Diff: 196 lines (+106/-19)7 files modifieddaemons/cache-database-replication-lag.py (+53/-0)
database/replication/helpers.py (+1/-0)
database/schema/comments.sql (+4/-0)
database/schema/patch-2207-28-1.sql (+9/-0)
database/schema/security.cfg (+6/-0)
database/schema/trusted.sql (+22/-0)
lib/canonical/launchpad/webapp/dbpolicy.py (+11/-19)
Changed in launchpad-foundations: | |
importance: | Undecided → High |
status: | New → Triaged |
assignee: | nobody → Stuart Bishop (stub) |
Changed in launchpad-foundations: | |
status: | Triaged → In Progress |
milestone: | none → 3.1.10 |
Changed in launchpad-foundations: | |
status: | Fix Committed → Fix Released |
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).