date:20220329

[Wikidata-bugs] [Maniphest] T303677: Automatically generate descriptions for items based on their P31 (instance of) values

2022-03-29 Thread Bugreporter

Bugreporter added a comment.


  For people the P106  value may be 
more useful than P31 .

TASK DETAIL
  https://phabricator.wikimedia.org/T303677

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Bugreporter
Cc: Bugreporter, Manuel, Nikki, Epidosis, Mahir256, Aklapper, Astuthiodit_1, 
karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, 
Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T289561: Evaluate Apache Rya as alternative to Blazegraph

2022-03-29 Thread So9q

So9q added a comment.


  Based on the discussion above I suggest closing this task.

TASK DETAIL
  https://phabricator.wikimedia.org/T289561

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: So9q
Cc: TheKtk, nguyenm9, Justin0x2004, Hannah_Bast, Gehel, Tpt, Smalyshev, So9q, 
Aklapper, Astuthiodit_1, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, 
CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, 
Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, 
Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T293862: Investigate using jvmquake to limit the time a JVM is unusable due to GC overhead

2022-03-29 Thread gerritbot

gerritbot added a comment.


  Change 773758 **merged** by jenkins-bot:
  
  [operations/alerts@master] team-search-platform: add jvmquake alerting
  
  https://gerrit.wikimedia.org/r/773758

TASK DETAIL
  https://phabricator.wikimedia.org/T293862

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: dcausse, gerritbot
Cc: bking, Aklapper, dcausse, Fernandobacasegua34, Astuthiodit_1, 786, Suran38, 
Biggs657, karapayneWMDE, Invadibot, Lalamarie69, MPhamWMF, maantietaja, 
Juan90264, Alter-paule, Beast1978, CBogen, ItamarWMDE, Un1tY, Akuckartz, 
Hook696, Kent7301, joker88john, CucyNoiD, Nandana, Namenlos314, Gaboe420, 
Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, Lucas_Werkmeister_WMDE, 
GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Lewizho99, Maathavan, 
_jensen, rosalieper, Neuronton, Scott_WUaS, Jonas, Xmlizer, jkroll, 
Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T274270: WDQS servers taking up to 30 minutes to reboot

2022-03-29 Thread bking

bking added a comment.


  Actions tried so far: disabling swap via systemd before rebooting. Worked on 
`wdqs2007`, did not work on `wdqs2002`. Also worth noting is that we had 
previously rebooted `wdqs2007` within the last 30 minutes, so a minor kernel 
update (from 4.19.0-16-amd64 to 4.19.0-20-amd64) or any other reboot-required 
updates could have fixed the issue. It's also possible the system hadn't been 
up long enough to cause any problems. Compare to `wdqs2002` which has been 
running a production workload and has not been rebooted recently.
  
  We will pick this up again tomorrow, attempting the systemd workaround linked 
in my last comment.

TASK DETAIL
  https://phabricator.wikimedia.org/T274270

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: bking
Cc: bking, RKemper, Gehel, Aklapper, Astuthiodit_1, karapayneWMDE, Invadibot, 
MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, 
Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, 
Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T274270: WDQS servers taking up to 30 minutes to reboot

2022-03-29 Thread bking

bking added a comment.


  This is still happening, @RKemper  found some interesting links that could 
explain this behavior:
  
  
https://wiki.freedesktop.org/www/Software/systemd/Debugging/#diagnosingshutdownproblems
  
  
https://old.reddit.com/r/archlinux/comments/ba3zec/very_slow_shutdownreboot_fixed/
  
  https://github.com/systemd/systemd/issues/11821#issuecomment-477545885
  
  I think it's worth trying the systemd workaround mentioned in the last github 
thread.

TASK DETAIL
  https://phabricator.wikimedia.org/T274270

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: bking
Cc: bking, RKemper, Gehel, Aklapper, Astuthiodit_1, karapayneWMDE, Invadibot, 
MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, 
Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, 
Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T304515: PHP Warning: Cannot use a scalar value as an array

2022-03-29 Thread Krinkle

Krinkle added a comment.

In T304515#7804508 ,
@Krinkle wrote:

> […]
> While I don't have a root cause answer to this error. I do know the
immediate cause of it. It seems these errors are only happening on POST
requests to Special:Badtitle, […].
>
> I haven't yet figured out what's making the requests, but I have found
what's causing the referer to be Badtitle. It seems the `ve.init.*` tests are
changing the address bar to Badtitle. […] This also has the side-effect of
breaking the QUnit UI when VE is installed.

I've managed to observe the POST requests locally by enabling (most) of the
CI-gated extensions locally. These are coming from GrowthExperiments' unit
tests, which are calling to `sendBeacon()` via EventLogging.

The reason the requests were seen by CI without an event payload (neither in
URL nor in body) will become apparent in a moment.

POST
/wiki/Special:JavaScriptTest#?%7B%22event%22%3A%7B%22newcomer_task_token%22%3A%221234%22%2C%22task_type%22%3A%22copyedit%22%2C%22maintenance_templates%22%3A%5B%5D%2C%22revision_id%22%3A102%2C%22page_id%22%3A101%2C%22page_title%22%3A%22Some%20title%22%2C%22has_image%22%3Afalse%2C%22ordinal_position%22%3A100%7D%2C%22schema%22%3A%22NewcomerTask%22%2C%22webHost%22%3A%22mw.localhost%22%2C%22wiki%22%3A%22foowiki%22%2C%22revision%22%3A-1%7D;
POST
/wiki/Special:JavaScriptTest#?%7B%22event%22%3A%7B%22newcomer_task_token%22%3A%221234%22%2C%22task_type%22%3A%22copyedit%22%2C%22maintenance_templates%22%3A%5B%5D%2C%22page_id%22%3A73%2C%22page_title%22%3A%22Some%20title%22%2C%22has_image%22%3Afalse%2C%22ordinal_position%22%3A0%7D%2C%22schema%22%3A%22NewcomerTask%22%2C%22webHost%22%3A%22mw.localhost%22%2C%22wiki%22%3A%22foowiki%22%2C%22revision%22%3A-1%7D;
POST
/wiki/Special:JavaScriptTest#?%7B%22event%22%3A%7B%22message%22%3A%22Parse%20error%20at%20position%200%20in%20input%3A%20%5B%5BTampa%2C%20Florida%7C%5D%5D%22%2C%22url%22%3A%22jqueryMsg%3A%2F%2Fpipe-trick%22%2C%22line%22%3A0%2C%22column%22%3A0%2C%22flowId%22%3A%2216485826419007%22%2C%22flowPosition%22%3A1%7D%2C%22schema%22%3A%22UploadWizardExceptionFlowEvent%22%2C%22webHost%22%3A%22wiki.xyz%22%2C%22wiki%22%3A%22foowiki%22%2C%22revision%22%3A-1%7D;
..
POST
/wiki/Special:Badtitle/JavaScriptTest#?%7B%22event%22%3A%7B%22message%22%3A%22Parse%20error%20at%20position%200%20in%20input%3A%20%5B%5B%5D%5D%22%2C%22url%22%3A%22jqueryMsg%3A%2F%2Fempty-link%22%2C%22line%22%3A0%2C%22column%22%3A0%2C%22flowId%22%3A%2216485832632794%22%2C%22flowPosition%22%3A3%7D%2C%22schema%22%3A%22UploadWizardExceptionFlowEvent%22%2C%22webHost%22%3A%22wiki.xyz%22%2C%22wiki%22%3A%22foowiki%22%2C%22revision%22%3A-1%7D;
HTTP/1.1

Note how there is a hash `#` between the end of the path and the start of the
would-be query string holding the event payload. This comes from
ext.eventLogging/log.test.js#7

which fails to restore the state afterwards. This is my fault (change 583183
),
both for not restoring it but also more broadly as being not working as
intended. See, I copied this from ext.eventLogging.debug.tests.js#77

for the original EventLogging service which used GET requests, and so by
setting the base URI to a hash I accomplished two things: 1) The feature is now
enabled for testing, and 2) It still doesn't go anywhere since navigations to
hash are a no-op. Except, that's not true for AJAX requests. And even then, it
most certainly isn't true for POST requests which will happen no matter what
and the hash just gets ignored.

In summary:

- In CI, we are seeing corruption that looks eerily familiar to the
php-opcache corruption we see in prod (T245183
).
- I explained at T304515#7804508
that this is strange given
we don't modify files. This might mean we just need to increase the size, or it
might mean php-opcache is worse than we thought and can cause this race even
during normal compiling of new files to opcache. If it's opcache related, then
the immediate cause would be the switch from php-webserver to php-fpm with
Apache. T285649
- The secondary cause is the bombarding of the server with POST requests.
These come from unit tests for GrowthExperiments and UploadWizard. These tests
are not at fault as EventLogging is meant to be no-op by default.
- The tertiary cause is that I broke EventLogging's tests.
- The quaternary cause is that VisualEditor's tests are

81 matches

Mail list logo