Currently we have a bunch of bugs where template wrapping or section wrapping fails (either generating some potentially-uneditable output or crashing the page) or possibly some other scenario where Parsoid cannot handle wrt supporting edits. Examples: T180534: Failed template encapsulation, T184779: Clean up a rare edge case in section-wrapping and extension-content interaction, T240642: Production crashers in WrapSections code because of missing properties ($dsr, $pi, $parts).
As we move towards Parsoid serving all read views, we should figure out a way of gracefully recovering from some (if not all) of these errors so even if the page is not editable, it should still render properly, i.e. we should not use HTTP 500 / 400 / 503 error codes as our VE-based-edit-prevention mechanism. We can instead recover from those error scenarios and mark an appropriate or the entire page uneditable via appropriate annotations. This can either be mw:Uneditable or mw:Error with additional information in data-mw that also tells VE how to handle the error wrt display and editing functionality.
This lets us move ahead with Parsoid read views without blocking on fixing or handling all the bugs / edge cases we have.
T180534 might be a good first test case for working through this mechanism.
Related: See https://gerrit.wikimedia.org/r/#/c/415992/
... a few things to happen. (a) protect the page from being edited via some error markup on the body tag (b) still generate HTML that enables the page to be read.
(a) is resolved as a requirement -- needs to be implemented.
(b) requires us to skip any dom passes that is editing-support only. It also requires adding defensive code in rendering-related passes that might inspect transclusion state.