Category update?

[mwjames]

Category update (or the lack of it) has been widely discussed [0] with [[Category:External identifier example]] [1] and [[Category:Sample_pages]] missing members.

Special:Ask [2] doesn't rely on MW's category table therefore can be queried and shows which pages are missing from the standard Category page display.

[0] https://www.mediawiki.org/wiki/Topic:Ta3n8f4l49wuqe9s
[1] https://sandbox.semantic-mediawiki.org/wiki/Cat%C3%A9gorie:External_identifier_example
[2] https://sandbox.semantic-mediawiki.org/w/index.php?title=Sp%C3%A9cial%3ARequ%C3%AAter&q=[[Category%3AExternal_identifier_example]]&po=&eq=yes&p[format]=broadtable&sort_num=&order_num=ASC&p[source]=&p[limit]=&p[offset]=&p[link]=all&p[sort]=&p[headers]=show&p[mainlabel]=&p[intro]=&p[outro]=&p[searchlabel]=...+further+results&p[default]=&p[class]=sortable+wikitable+smwtable&p[sep]=&eq=yes

[kghbln]

I believe this is unrelated and on sandbox caused by the following setting:

## Expiry
$wgParserCacheExpireTime = 7 * 24 * 3600;

By default this setting is one day.

[mwjames]

I believe this is unrelated and on sandbox caused by the following setting:
By default this setting is one day.

A week but doing a manual purge should destory/evict the parser cache, yet nothing happens.

Expected members are:

Page	Modification date
EC number	07:12:09, 20 November 2016
Has population	15:41:33, 3 December 2016
NDL ID	07:38:09, 20 November 2016
Triacylglycerol lipase	10:27:58, 20 November 2016
WD:P	07:12:42, 20 November 2016
WD:Q	07:14:40, 20 November 2016

[0] https://sandbox.semantic-mediawiki.org/w/index.php?title=Sp%C3%A9cial%3ARequ%C3%AAter&q=[[Category%3AExternal_identifier_example]]&po=%3FModification+date%23LOCL%0D%0A&eq=yes&p[format]=broadtable&sort_num=&order_num=ASC&p[source]=&p[limit]=&p[offset]=&p[link]=all&p[sort]=&p[headers]=show&p[mainlabel]=Page&p[intro]=&p[outro]=&p[searchlabel]=...+further+results&p[default]=&p[class]=sortable+wikitable+smwtable&p[sep]=&eq=yes

[kghbln]

Ah, I only checked "Has population" and figured all the other members date back to this day too. Well the others should indeed already shown up. Just checked the job queue and there are some jobs stuck, however unrelated ones. I will now run "rebuildLinks.php" to see where we can go from there.

[kghbln]

Running "rebuildLinks.php" helped and now all the pages show up in the category. Still, a manual purge should have done the job for individual pages. I am not sure what the issue may be since the jobs are being worked on by cron and there are no other cache related settings deviating from their defaults.

[kghbln]

Closing for now though I have the feeling that this is not a one time show up thingy. So just reopen as soon as ...

[kghbln]

I am fed up of this bullsh. Categories basically stopped propagating after switching to MW 1.28

[kghbln]

https://www.mediawiki.org/wiki/Topic:Tmfy6f9chbhg584i

[kghbln]

php refreshLinks.php

Deleting illegal entries from the links tables...
  Checking interval (-INF, INF)
    pagelinks: 0, 1 deleted.
    imagelinks: 0 deleted.
    categorylinks: 0, 2 deleted.
    templatelinks: 0, 2 deleted.
    externallinks: 0, 1 deleted.
    iwlinks: 0 deleted.
    langlinks: 0 deleted.
    redirect: 0 deleted.
    page_props: 0, 6 deleted.

I wonder where all these illegal entries come from.

[kghbln]

Getting closer to what may probably make the link updates fail:

2017-03-09 17:12:39 refreshLinks Modèle:Protocol_Endpoint pages={"118":[0,"Protocol37"]} rootJobSignature=c1d283b32c913664e4a7f10af5323f06669bada1 rootJobTimestamp=20170309170252 triggeredRecursive=1 requestId=0f02d22c76de81caa099df10 (id=25276,timestamp=20170309170605) t=184 error=DBUnexpectedError: LinksUpdate::acquirePageLock: Cannot flush pre-lock snapshot because writes are pending (SMW::writePropertyTableRowUpdates-delete-smw_fpt_askdu, SMW::writePropertyTableRowUpdates-insert-smw_fpt_askdu, SMWSql3SmwIds::setPropertyTableHashes, Database::onTransactionPreCommitOrIdle, Title::invalidateCache).

in short

error=DBUnexpectedError: LinksUpdate::acquirePageLock: Cannot flush pre-lock snapshot because writes are pending (SMW::writePropertyTableRowUpdates-delete-smw_fpt_askdu, SMW::writePropertyTableRowUpdates-insert-smw_fpt_askdu, SMWSql3SmwIds::setPropertyTableHashes, Database::onTransactionPreCommitOrIdle, Title::invalidateCache

This happens all along the way.

@mwjames Is this something I should open up a bug for? I suppose so.

gist containing all console output. About 500 job went bellies up, i.e. attempt=1

[mwjames]

Hi,

requestId=0f02d22c76de81caa099df10 (id=25276,timestamp=20170309170605) t=184 error=DBUnexpectedError: LinksUpdate::acquirePageLock: Cannot flush pre-lock snapshot because writes are pending

I've seen https://phabricator.wikimedia.org/T153618, https://phabricator.wikimedia.org/T154428 in regards to "Cannot flush pre-lock ...". Cheers

…

On 3/10/17, Karsten Hoffmeyer ***@***.***> wrote: Getting closer to what may probably make the link updates fail: ``` 2017-03-09 17:12:39 refreshLinks Modèle:Protocol_Endpoint pages={"118":[0,"Protocol37"]} rootJobSignature=c1d283b32c913664e4a7f10af5323f06669bada1 rootJobTimestamp=20170309170252 triggeredRecursive=1 requestId=0f02d22c76de81caa099df10 (id=25276,timestamp=20170309170605) t=184 error=DBUnexpectedError: LinksUpdate::acquirePageLock: Cannot flush pre-lock snapshot because writes are pending (SMW::writePropertyTableRowUpdates-delete-smw_fpt_askdu, SMW::writePropertyTableRowUpdates-insert-smw_fpt_askdu, SMWSql3SmwIds::setPropertyTableHashes, Database::onTransactionPreCommitOrIdle, Title::invalidateCache). ``` -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #22 (comment)

[kghbln]

I've seen https://phabricator.wikimedia.org/T153618

So we can wait endlessly for 1.28.1

https://phabricator.wikimedia.org/T154428

Sitting tight, too.

Thanks for the links.

[kghbln]

Yeah, 1.28.0 was broken in this respect. Touching wood and thanks for the phab links!

[kghbln]

All broken again in 1.29.0-rc0 and beyond: https://phabricator.wikimedia.org/T168723 This seems to have been borked inherently.

[mwjames]

All broken again in 1.29.0-rc0 and beyond: https://phabricator.wikimedia.org/T168723 This seems to have been borked inherently.

I'm making a conjecture that this relates to [0] based on findings in connection with properties missing updates due to a hidden exception which made the search for a cause inherently difficult. Since the category update relies on `DeferredUpdate` as well, I wouldn't be surprised if their share some similar symptoms or exceptions that prevent the actual update to take place. [0] https://phabricator.wikimedia.org/T168347 Cheers

…

On 6/27/17, Karsten Hoffmeyer ***@***.***> wrote: All broken again in 1.29.0-rc0 and beyond: https://phabricator.wikimedia.org/T168723 This seems to have been borked inherently. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #22 (comment)

[kghbln]

Thanks for the info. I created a connection on Phabricator between the two issues.

[kghbln]

Assuming that this is finally in fluff now.