Closed Bug 1209025 Opened 10 years ago Closed 9 years ago

Revert doesn't update content in the view

Categories

(developer.mozilla.org Graveyard :: General, defect)

Product:
developer.mozilla.org Graveyard
Component:
General
Platform:
All
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jsx, Assigned: jezdez)

References

Details

(Keywords: in-triage, Whiteboard: [specification][type:bug])

What did you do? ================ 1. Reverted spam edit in https://developer.mozilla.org/en-US/docs/MDN/Getting_started to a previous good revision. 2. Checked the page again after reverting: * I checked force refresh * Checked after an hour * Checked on a virtual machine inside a remote network. What happened? ============== Page content wasn't updated to the previous revision I had reverted to. Still shows the now older spam content. What should have happened? ========================== The page content is reverted if you check in the edit view, but the revert isn't effected in the actual page display. Is there anything else we should know? ====================================== I've encountered this issue before. You could go to the edit view and save the page and the content displayed will be updated, but leaving it as is as it might aid in debugging the issue. Probably related to bug 888072
Ok, since it's a high traffic page, I'm editing and saving the page so that the spam content is overwritten from the view.
This is a regression. See bug 839819, bug 888072, and bug 950231.
Just noting that I've been encountering more of these lately. Happened for both the edits I reverted today.
I've also got a couple of occurrences when reverted. I'm wondering if it happens 100% of the time when reverting now.
I wasn't able to reproduce this on my test page: https://developer.mozilla.org/en-US/docs/User:groovecoder I reverted, did a force-refresh, and saw the reverted content. Please keep track of which pages it happens on so we can try to spot a pattern with them.
I was able to reproduce the issue. Steps: 1) New user jsxtest edited existing page https://developer.mozilla.org/en-US/docs/User:jsx 2) Existing user jsx reverted the page 3) Revert didn't take effect
No longer depends on: 1228524
Confirming. Workaround for now: Revert and trigger a manual force-refresh (ctrl-F5).
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Florian Scholz [:fscholz] (MDN) from comment #9) > Workaround for now: Revert and trigger a manual force-refresh (ctrl-F5). Manual force-refresh (ctrl-F5) never worked for me. Instead I just edit the page and save with just an edit comment.
So this seems to be a regression from bug 1174498 and https://github.com/mozilla/kuma/pull/3483
Assignee: nobody → jezdez
Status: NEW → ASSIGNED
Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/af90da39da1b996444eea4c1088241a3268a61ba Bug 1209025 - Only schedule the rendering task after the database transaction has been committed. This is a regression of bug 1174498. https://github.com/mozilla/kuma/commit/c506360b5c7085c8a1213693ac1f8a1d8af3d989 Bug 1209025 - Explicitly set based_on of the reverted revision and do primary comparison checks. Also: - add some code comments for easier understanding - handle database transaction inside model method, not view - refresh model instance before making revision the current one by resetting ORM object with related info https://github.com/mozilla/kuma/commit/689ece637247258d245e81ec2028e3e3b548767d Bug 1209025 - Remove explicit setting of CELERY_ALWAYS_EAGER setting since that's the default in testing. https://github.com/mozilla/kuma/commit/e6b91040e3606becb8501ce21df7baa86f13c128 Merge pull request #3761 from mozilla/bug1209025 Bug 1209025 - Fix some regressions in the revert view.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.