Currently, we get the revid and timestamp information from the API, which gets them from the DB right before or after issuing the Parsoid request, assuming they'll be the same. That's fragile but also silly, because we should be getting this information from the Parsoid HTML's <head> instead.
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Catrope | T90374 Retrieve page HTML directly from RESTbase | |||
| Resolved | Krenair | T92993 Handle page content data being for a different revision compared to the API-added data |
Event Timeline
Comment Actions
The revision's timestamp should be in the parsoid HTML so it can be edited without having to get more data from the API. (The API requires it for conflict detection.)
Roan was speaking earlier about trying to move the 'editingold' message to the client (which is messy because that has to be parsed server-side), but a lot more than that would break if/when they return different IDs... Page existence, protection, etc. So we should error or retry (with the higher ID) when we get different IDs from RESTBase and VE-MW.
Comment Actions
Me and Roan talked and agreed that we should take the revision IDs from both pieces of data and retry the older one if it's for a different revision. It should probably be kept in mind for T90374: Retrieve page HTML directly from RESTbase
Comment Actions
It turns out we already have this:
<meta property="dc:modified" content="2015-03-19T23:26:34.000Z"/>
Which, based on the Parsoid source, is the rev_timestamp.
(But this is probably irrelevant now.)
Comment Actions
Change 198393 had a related patch set uploaded (by Alex Monk):
Check for the two revision IDs returned by the server being different
Comment Actions
Change 198393 merged by jenkins-bot:
Check for the two revision IDs returned by the server being different