In T264257 after ParserCache corruption the temporary code was added to RejectParserOutput hook handler to reject the corrupted values. However, the hook was run too late and ParserCache code already had a chance to explode before reaching the hook. We should try moving the hook call cite as early as possible, perhaps even running the hook multiple times with nulls instead of the values that are still unknown. Ideally we need to run the hook in the very beginning of the ParserCache::get (and possibly ParserCache::getKey) methods.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • Pchelolo | T250500 ParserCache / RESTBase / Parsoid integration | |||
| Declined | • Pchelolo | T264348 Run RejectParserOutput hook much earlier, possibly multiple times |
Event Timeline
Comment Actions
@Pchelovek1205 and @WDoranWMF if T264348 Run RejectParserOutput hook much earlier, possibly multiple times is a child of T250500 ParserCache / RESTBase / Parsoid integration, should it be an epic instead of a different initiative on the roadmap?
It also looks like this initiative didn't go through our decision-making process and appeared, why is that?
Comment Actions
Ok, I've found one downside of making an initiative board - the tags are getting inherited and I've accidentally tagged this with roadmap when creating subtask. This is not an initiative, not an epic. It's a small improvement.