Mostly used find-and-replace:
Find:
/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?)[\s\*]+/\s*(private|protected|public) (\$[a-z]\w+;\n)((?=\s*/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?))\n|)
Replace with:
\3 \1 \4
More could be done, but to keep this patch reasonably sized, I only
changed the most obvious and unambiguously correct cases.
In some cases, I also removed redundant doc comments on the
constructor, and re-ordered the properties to match the constructor.
Change-Id: I7eb97640c0543ae10bf2431623a5f7efdc3349b7
This allows HtmlOutputRendererHelper to function for all kinds of
content.
Bug: T311728
Bug: T311648
Bug: T359426
Change-Id: Ib32af7cf2a7ad989eb0b13ecca37c857fc9199ec
PoolCounterWorkArticleView was not designed for use by all callers of
getParserOutput. It provides stampede protection but does not generally
prevent duplicate concurrent parsing, and it may result in stale cache
entries being returned to the caller. This is acceptable for page views,
but not other use cases like editing or updating secondary derived data.
Bug: T352837
Change-Id: Ie532c17e5b86e8e1adbb57ecd5c5c6405b83bf8f
Two of the classes in this directory have already namespaced to
MediaWiki\PoolCounter.
Bug: T353458
Change-Id: Ie41f8d935f7623bb40040a5eb78f99c6d7b7b75e
Entries were never removed from this cache, causing memory leaks in
long-running scripts.
Bug: T315510
Change-Id: I5131f2ca19db9981218273bde0dd0f975157ccdb
* This reverts commit c1b82097.
* This reverts commit 56025174.
* This updates a test change from commit c8d0470f.
* Now that ParsoidOutputAccess has become a thin wrapper over
ParserOutputAccess and the code has landed in production without
needing to be reverted, we can revert the above hacks as soon as the
hits from the 'parsoid' instance start to go down to a small number.
As of the time of creating of this patch, of the combined hits to the
'parsoid' and 'parsoid_pcache' instance, over 90% are now from the
'parsoid_pcache' instance. We can wait for a couple more days to
watch how this number changes.
* Note that once we deploy this patch, the accesses which would have
hit in the 'parsoid' instance (with this hack) will instead result
in a cache miss thus adding the full parse latency to REST API
requests (whether by VisualEditor or by other clients). So, we need
to figure out what the cutoff point is. While 3 weeks is a guaranteed
switchover timeframe (because all entries in 'parsoid' cache will
expire at that time and we'll get no more hits from there after that),
note that we are at < 10% hits in this cache just 4 days after the
train rollout. So, there is a good chance we could get beyond 95%
by the end of this week.
Bug: T347632
Change-Id: Ibd741b92b860b4d4b03ca220863debaf53fab44a
When the latest revision of a page was requested from
ParserOutputAccess, then the page was edited within the same
PHP process, and then the new latest revision of a page was
requested, it would return the result for the old latest
revision. The $isOld checks did not prevent this, because at
the time of checking, the two revisions were both the latest.
Compare the latest revision ID (not just whether it's the
latest revision) to avoid this.
Bug: T349033
Change-Id: I386b4a9b791065fb39dcfb2cb6df9f321d540ae1
* ParsoidOutputAccess used a 'parsoid' ParserCache instance and did not
set the 'useParsoid' parser option for tier 2 ParserOutput cache key
computations.
* ParserOutputAccess uses 'pcache' for legacy parser output and
'parsoid-pcache' for Parsoid parser output objects based on whether
'useParsoid' parser option is true or false.
* 'parsoid-pcache' is right now very sparsely populated since useParsoid
is only used for testing.
* In Ic9b7cc0fcf36, where we make ParsoidOutputAccess a thin wrapper
over ParserOutputAccess, all Parsoid parser output requests will go
to ParserOutputAccess's 'parsoid-pcache' instance which is sparsely
populated and hence will result in a lot of cold cache misses.
* To eliminate this scenario, this patch adds hardcoded hacks to both
ParserOutputAccess and ParserCache to query the 'parsoid' PC instance
on cache misses to the 'parsoid-pcache' instance. Over a 3-week
period, as 'parsoid-pcache' fills up, there will be fewer and fewer
access to the 'parsoid' PC instance which will also expire. At the
end of that period, we can remove this hack.
T347632 tracks removal of these hacks.
* Added new PHP unit test verifying that the hack work as intended.
Bug: T332931
Change-Id: I7f933fd61bf358c6ea0e0c1202231cac618f9e8d
This patch makes two major changes:
- In the PoolCounter chain, we simply inject CP and call it directly
and as result, there is no need for ILBF::getChronologyProtectorTouched
- Instead of injecting CP callback to LB, just pass the object down the
chain which leads to simpler and more stable code.
Bug: T275713
Change-Id: If78f4498d98e256015e54cc46561cb11b2947058
This class is used heavily basically everywhere, moving it to Utils
wouldn't make much sense. Also with this change, we can move
StatusValue to MediaWiki\Status as well.
Bug: T321882
Depends-On: I5f89ecf27ce1471a74f31c6018806461781213c3
Change-Id: I04c1dcf5129df437589149f0f3e284974d7c98fa
Triggering an opportunistic LinksUpdate on every cache miss of the
current revision might not be appropriate in some cases.
Some functions like ContentHandler::getParserOutputForIndexing might
be called after all LinksUpdates but if these functions do explicitely
disallow populating the parser cache via OPT_NO_UPDATE_CACHE we might
enter a case where involved jobs would trigger themselves forever.
It is happening in the case of the CirrusSearch extension that listens
to LinksUpdate and is relying on
ContentHandler::getParserOutputForIndexing to fetch the parser output.
Introduce a new option ParserOutputAccess::OPT_LINKS_UPDATE to be
more intentional on whether such cascading LinksUpdate might occur
or not on cache misses.
Change the default to not trigger a LinksUpdate on every cache miss
and enable it only when rendering the article view (Article::view).
It does not seem ideal that this behavior is owned by the ParserCache
and further refactoring might be needed to separate these concerns.
Bug: T329842
Change-Id: Ib3c3ca935f316ea880ff6c6b393fa80166e42bd3
Uses flag to detect which cache instance to use based on ParserOptions
and sets the primary and secondary caches accordingly. This ensures
that the ParserCacheMetadata cache used by the ParserCache is also
appropriately forked for Parsoid, as Parsoid may consult different
options in the ParserCache than core does.
A follow up patch will attempt to refactor this to be less
parsoid-specific.
Bug: T327769
Bug: T330677
Co-authored-by: Alangi Derick <alangiderick@gmail.com>
Change-Id: Id580b97ad9a0b90bbe56d4de3c2f999274fe329b
If the revision id is null, the item should not be cachable.
However, you still need a poolcounter work key for such cases,
and this method was used for both. This is confusing and seems
dangerous, so split into two methods, one where a revision id
is required, and another one where it is optional that should
only be used when it is not for a cache key.
This also fixes a warning about null revId on php 8.1 in tests.
Bug: T313663
Change-Id: Id685caeecf21d058bfd8446d9b5e21f0f11e0177
Small, non-functional changes to make the code more readable.
* No need to expose the subclassing in newPoolWorkArticleView(). All
the user needs to know is that PoolCounterWork::execute() can be
called.
* The doWork() method exists to be called from PoolCounterWork. Each
subclasses should do this independently from the others.
Another benefit is that we can have more strict type declarations.
Change-Id: I9418169e8937029f61d15ad54a1afeec0b343bb9
* Indicate whether a class is a service (to be found via MediaWikiServices)
or a lower-level class for certain backend logic.
* Indicate how to create / where to get instances of non-service classes,
e.g. point to the relevant service.
* Remove copy-pasta text in file docblock that is unrelated,
and incorporate any relevant text into the class docblock instead.
Change-Id: Ia3b9b8c22da4d7160c5e14ae6a6a7c9dca30e9db
All these methods have been written to return true, but that value was
never used for anything other than realizing that the method succeeded.
The ParserOutput object we are interested in was stuck in a property.
Why not return the ParserOutput object?
I wrapped it in a Status object to be able to pass warning messages
along with the actual result. There was even more specialized code to
do that via dedicated setters and getters. All this can be removed now.
Bug: T304813
Change-Id: I6fd3745835dfcaec94695469498a2662f8317c35
There is only a single subclass that ever does anything with these
two boolean properties. Only 3 states are possible. Pretty much all
of this belongs to the subclass. No other code should have to know
anything about this.
This patch doesn't fully solve the issue but moves code in the
described direction.
Bug: T304813
Change-Id: I70754546f065b03ff04a73307c10f22fbb040810
Usually we opt to break access control in a test, rather than expose
internals in production classes.
Change-Id: I7e393d2569e8784e2c8eb7ed29d60aab58b9bd83
The idea is to group code that belongs together:
1. The status is created and fix-ups applied.
* The result is stored.
* Fix an invalid status that claims to be ok but doesn't have a
result.
* Note we might have a non-null result at this point that's
marked as erroneous.
2. Some additional things that are only done when it was a success.
3. Logging/stats stuff is something entirely separate.
Change-Id: I541eff1a64d113c48223c4ce76d79ae5fe08a018
There is a chance a revision is given, but it's the latest one. This
will be cached, but never used because of the check in line #217.
Change-Id: Ic74a16f6647672d7619ce0d736ef931721362f67
The same check is done in multiple places, just slightly different
every time, but always boiling down to the same idea: The latest
revision is requested either when it's specifically requested or
missing. Otherwise it's an old one.
The only purpose of this patch is to make the code easier to read.
I made sure there is zero functional change.
Bug: T304813
Change-Id: I0a5c84eb137dfbbefb1ef57eaf8711971b991911
Remove some single-use variable names. This reduces mental load. No
need to check if a variable might be used for something else later.
The code duplication is minimal, only single lines. This makes it
very easy to parse mentally.
The reason why I touch this code in the first place will become more
obvious in the following patches.ParserOutputAccess
Change-Id: I73fc5d45034ae6ce93b198b956f783f95900d155
This is needed to make sure CirrusSearch doesn't overwhelm parsercache.
Follows-up I23c053df4c (T302620).
Bug: T285993
Change-Id: Ia5fc3b063c45cb43fdee16f44da2270847773945
The equality check is unnecessary, the switch-case construct
does it. The code should work the same:
When $useCache is equal to CACHE_SECONDARY, the expression
evaluates to true and so does the loose comparison done by
the switch.
Otherwise it evaluates to false and the case is false, too.
Follow-Up: I0fe275b4991f1bf89c7bb587132bc4fb0ea862e2
Change-Id: I2ded074d4e31d5770c02b4d5ac4acc58b8542ad0
This is similar to the rest of the class, caching if revision is not
specified or it's the latest.
This helps in cases when revision is being passed to getParserOutput()
like FlaggedRevs
Bug: T283029
Change-Id: Ia5c5c112a033944689259c2d2839faf4a8bd90e0
This guards against duplicate parses.
These happen when a page is parsed but an extension needs the
ParserOutput again in the same request when it hasn't made into the
ParserCache yet, or if it is considered uncachable. In that case we
still want to allow re-use within the same process.
Bug: T301310
Change-Id: I1ddd967a40b760b1e53f1fd227cb0d0732f78ec1
Still needs to downcast to WikiPage in 2 places:
1. To check get a ContentHandler and check if content model
is cacheable. We probably should just make all content models
cacheable.
2. To call WikiPage::triggerOpportunisticLinksUpdate. I have
an elaborate plan for this one, but it will be done separately.
Change-Id: Ifd9ab0155dc1fad0c1608dafea05d16292afd057
Stubthreshold option used to be a cache-varying option,
but in all places where we interact with the ParserCache
we are checking that it's 0 before using the cache.
Instead, we can just remove all the special cases for
stubthreshold option, remove it from cache key and rely
on ParserOptions::isSafeToCache to avoid caching non-default
stubthreshold outputs.
Bug: T264351
Change-Id: Ifaf69a3e651eef21c88da3aa3044b490059958ca
