Page MenuHomePhabricator

Make Parsoid/PHP cluster read-write to ensure lints discovered by Parsoid/PHP are stored in the DB
Open, MediumPublic

Description

So far, we have left scandium and the Parsoid/PHP cluster in read-only mode to prevent lints from being recorded during the early test phases.

But, before we get to live traffic mode, we should verify that lints are written to the DB correctly and that there are no errors as a result. We may decide to temporarily disable linting in Parsoid/JS during this test.

Event Timeline

ssastry triaged this task as Medium priority.Nov 4 2019, 9:29 PM
ssastry created this task.
ssastry moved this task from Backlog to Deployment on the Parsoid-PHP board.Nov 5 2019, 5:54 PM
cscott added a subscriber: cscott.Nov 6 2019, 5:09 PM

If it were possible to direct writes at some *other* database before pointing them at the live database, that might be a good "step #0".

But if we can't do that easily, I'm fine with the idea that we enable Parsoid in "live use for linting" before turning on Parsoid for "live use for editing".

Arlolra added a subscriber: Arlolra.Nov 6 2019, 6:52 PM

One thing to consider (maybe a separate bug needs filing) is that Parsoid/JS has been sending dsr info that has been used in browser by JS to show where errors occur in the markup. dsr info from Parsoid/PHP is using a different encoding so the offsets might not line up. We probably want to clear out old lints and then update the Linter extension to account for the difference.

One thing to consider (maybe a separate bug needs filing) is that Parsoid/JS has been sending dsr info that has been used in browser by JS to show where errors occur in the markup. dsr info from Parsoid/PHP is using a different encoding so the offsets might not line up. We probably want to clear out old lints and then update the Linter extension to account for the difference.

Good catch. This is a more serious issue. We should pause lint collection OR disable the Linter extension while we figure out how to handle this. If the Linter JS code cannot handle byte offsets, we would have to introduce conversion code in Parsoid/PHP for lint purposes => we add additional overheads beyond linting to every single parse request.

Given the above, I am going to remove this as a deployment subtask. This is blocked by T237569.

For ow, given T238456: Missing implementation to post Parsoid/PHP lints to production database, we may just go with posting to the linter API instead of direct writes to the DB. We can resurrect this later when we get around to doing direct writes.