tstarling added subscribers: bzimport, tstarling.
tstarling added a comment.
In https://phabricator.wikimedia.org/T43103#442763, @bzimport wrote:
**bugzilla.wikimedia** wrote:
(In reply to comment #8)
... We really need to be able to get Language objects without
loading all
tstarling added a subscriber: tstarling.
tstarling added a comment.
The API output is correct. That parser function returns no text, and sets a
property with name wpb-banner-options. The extension uses a BeforePageDisplay
hook to modify the HTML depending on the wpb-banner-options property
tstarling changed the title from Pagebanner extension and api=parse and
api=expandtemplates endpoinds to Parsoid has no special handling for the
properties set by WikidataPageBanner.
TASK DETAIL
https://phabricator.wikimedia.org/T107941
EMAIL PREFERENCES
https://phabricator.wikimedia.org
tstarling moved this task to Under discussion on the MediaWiki-RfCs workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T114443
WORKBOARD
https://phabricator.wikimedia.org/project/board/52/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
tstarling added a project: MediaWiki-Platform-Team.
TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, tstarlingCc: SBisson, Izno, Pppery, Alsee, Florian, Liuxinyu970226, WMDE-leszek, Mholloway
tstarling added a project: SQLite.Herald added a project: Wikidata.
TASK DETAILhttps://phabricator.wikimedia.org/T44688EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: wikibugs-l-list, Wikidata-bugs, Abraham, Denny, aude, daniel, Unknown Object
tstarling added a project: SQLite.Herald added a project: Wikidata.
TASK DETAILhttps://phabricator.wikimedia.org/T44689EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: wikibugs-l-list, Wikidata-bugs, Denny, Lydia_Pintscher, daniel, Unknown Object
tstarling removed a parent task: T22257: SQLite support (tracking).
TASK DETAILhttps://phabricator.wikimedia.org/T44688EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: wikibugs-l-list, Wikidata-bugs, Abraham, Denny, aude, daniel, Unknown Object
tstarling removed a parent task: T22257: SQLite support (tracking).
TASK DETAILhttps://phabricator.wikimedia.org/T44689EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: wikibugs-l-list, Wikidata-bugs, Denny, Lydia_Pintscher, daniel, Unknown Object
tstarling added a comment.
If you just want an approximately PCRE-like syntax, you could just translate the regex to a Lua pattern. Scribunto has equivalent code going in the other direction, in Scribunto_LuaUstringLibrary::patternToRegex(), which you could look at for ideas. Obviously you would
tstarling closed subtask T178538: Bump PHP requirement to 5.6 in 1.31 as "Declined".
TASK DETAILhttps://phabricator.wikimedia.org/T170281EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: Paladox, Ricordisamoa, PokestarFan, thiemow
tstarling closed this task as "Resolved".tstarling claimed this task.tstarling added a comment.
The fix is merged, and searching logstash for SiteConfiguration shows no further errors of this type.TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFER
tstarling assigned this task to Anomie.
TASK DETAILhttps://phabricator.wikimedia.org/T183489EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlingCc: Jdforrester-WMF, Aklapper, aude, Addshore, Anomie, daniel, Lahi, PDrouin-WMF, Gq86, E1presidente
tstarling assigned this task to Anomie.
TASK DETAILhttps://phabricator.wikimedia.org/T182678EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlingCc: gerritbot, Anomie, aude, Aklapper, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007
tstarling added subscribers: Addshore, tstarling.tstarling added a comment.
This is on our workboard and Q3 goal list but https://wikifarm.wmflabs.org/mcr/index.php/Main_Page has it assigned to Adam, I assume that is @Addshore. Is it OK to assign this task?TASK DETAILhttps
tstarling assigned this task to Anomie.
TASK DETAILhttps://phabricator.wikimedia.org/T174032EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlingCc: Aklapper, daniel, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF
tstarling removed a subtask: T161598: Monitor HHVM bytecode cache depletion on mediawiki app servers.
TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: tstarling, thcipriani, Anomie, aaron
tstarling added a comment.
Daniel proposed the following schedule:
Today: test2wiki, testwikidatawiki
This week (WN31): mediawikiwiki, metawiki
Next week (WN32): wikidatawiki, commonswiki
Week after (WN33): everything
I'm going to start on this now.TASK DETAILhttps://phabricator.wikimedia.org
tstarling added a comment.
test2wiki and testwikidatawiki are complete.TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlingCc: tstarling, Stashbot, Abit, gerritbot, Jdforrester-WMF, Anomie
tstarling closed subtask T197816: Enable MCR migration stage "write both, read old" on live systems as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T194750EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: Cparle, Ak
tstarling closed subtask T197816: Enable MCR migration stage "write both, read old" on live systems as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlin
tstarling closed this task as "Resolved".tstarling claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T197816EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: Aklapper, gerritbot, aude, Addshore, Anomie, Jdforrester-WMF, Ab
tstarling added a comment.
In T198049#4310346, @jcrespo wrote:
51,715 exceptions with:
[{exception_id}] {exception_url} Wikimedia\Rdbms\DBReplicationWaitError from line 426 of /srv/mediawiki/php-1.32.0-wmf.8/includes/libs/rdbms/lbfactory/LBFactory.php: Could not wait for replica DBs to catch up
tstarling added a comment.
db1071, the master, had no writes
It actually had a factor of 10 fewer writes, not zero writes.
I'm pretty sure there was no outage.
I had a closer look at the exceptions. Most of them came from jobs. There's a sizeable minority that came from appservers. Sampling
tstarling closed this task as "Resolved".tstarling added a project: Core-Platform-Team (CPT-Q1-Jul-Sep-2018).tstarling claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T198049EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: t
tstarling added a comment.
So how do we end up trying to insert a row for revision 3003 twice?
max(rev_id) on this wiki is 3002, so the ar_rev_id certainly came from populateArchiveRevId.php, which allocated ar_rev_id values by inserting dummy rows into revision and deleting them in the same
tstarling created this task.tstarling triaged this task as "Normal" priority.tstarling added projects: Structured-Data-Commons, Multi-Content-Revisions (MCR Deployment), Core-Platform-Team (CPT-Q1-Jul-Sep-2018).Restricted Application added a subscriber: Aklapper.Restricted Applica
tstarling added a comment.
In T183488#4499288, @jcrespo wrote:
@tstarling Please stop writes going to *s2* unless they have already finished
Done. s2 was up to itwiki rev_id 3012040.
enwiki should take about another 6 days at the current rate.TASK DETAILhttps://phabricator.wikimedia.org
tstarling added a comment.
Log summary:
aawikibooks failed with "Error: 1062 Duplicate entry '3003-1' for key 'PRIMARY' (10.64.0.205)"
cawiki failed with "Replication wait failed: Server shutdown in progress" and will need to be restarted.
gotwikibooks also failed with a du
tstarling added a comment.
You can see the full logs at mwmaint1001:/var/log/mediawiki/populateContentTables/ . On both aawikibooks and gotwikibooks, the error occurred on the second batch of the archive table, starting at ar_rev_id 2001. In both cases it was also the last batch, with the maximum
tstarling added a comment.
Current status: everything is done except enwiki and the T202032 wikis. enwiki has about another 49 hours to run.TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc
tstarling added a comment.
The drop may have been caused by the API maxlag parameter. Wikidata:Bots recommends using a maxlag parameter, and some client libraries set maxlag=5 by default. The point of this feature is to make bots pause during replication lag, to prioritise human users and avoid
tstarling added a comment.
@greg The WN31 things are done now, only 1081 seconds for mediawikiwiki and 9252 seconds for metawiki. For metawiki the rate was about the same as anomie got for testwiki, 2000 rows per second for the revision table and 600 rows per second for the archive table
tstarling reassigned this task from tstarling to Anomie.
TASK DETAILhttps://phabricator.wikimedia.org/T202032EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlingCc: gerritbot, Aklapper, daniel, aude, Addshore, Anomie, Abit, jcrespo, tstarling
tstarling added a comment.
BlobStoreFactory has a single LoadBalancer injected into its constructor, but allows the caller to choose the wiki ID in newSqlBlobStore(). So that's wrong. Wikidata just gets the BlobStoreFactory from MediaWikiServices::getBlobStoreFactory(), which doesn't allow you
tstarling added a comment.
Passing the wrong LoadBalancer into the SqlBlobStore constructor would have approximately this effect. The "previous.trace" is:
#0 /srv/mediawiki/php-1.32.0-wmf.18/includes/libs/rdbms/loadbalancer/LoadBalancer.php(768): Wikimedia\Rdbms\Lo
tstarling added a comment.
enwiki is complete now, so only the T202032 wikis remain.TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: jcrespo, greg, tstarling, Stashbot, Abit, gerritbot
tstarling added a comment.
In T182348#3883001, @ArielGlenn wrote:
It should be back on php5 now, I went through all the misc dumps crons, made sure they all use the config setting for php in the dumps config, and that is php5. See https://gerrit.wikimedia.org/r/#/c/400692/
Why would you revert
tstarling added a comment.
In T198492#5471572 <https://phabricator.wikimedia.org/T198492#5471572>,
@Anomie wrote:
> Maybe that was true 15 years ago, but update.php seems well-established now.
No, it was never true. update.php has been used to drop fields since MW 1.5,
14
tstarling added a comment.
In T238575#5672789 <https://phabricator.wikimedia.org/T238575#5672789>,
@Lucas_Werkmeister_WMDE wrote:
> In `getCandidateClients()`, the return value ultimately comes from
`IDatabase::selectFieldValues()`, implying that we have some
`wb_changes_dispa
tstarling added a comment.
There is https://pecl.php.net/package/re2 . It was written for PHP 5 and was
never updated after its initial release in 2011, but we have the skills to
update it for PHP 7 and review it for security. If we believe in RE2 then we
shouldn't be afraid to invest
tstarling added a comment.
This proposal is effectively a dynamic rate limit except that instead of
delivering an error message when it is exceeded, we will just hold the
connection open, forcing the bot to wait. That's expensive in terms of server
resources -- we'd rather have the client
tstarling added a comment.
Really the client has to wait every time, so there needs to be a delay hint
header like Retry-After with every response. So it's not exactly maxlag=auto.
TASK DETAIL
https://phabricator.wikimedia.org/T252091
EMAIL PREFERENCES
https://phabricator.wikimedia.org
tstarling added a comment.
In T240884#6392690 <https://phabricator.wikimedia.org/T240884#6392690>,
@Lucas_Werkmeister_WMDE wrote:
> I wonder if T260330: PHP microservice for containerized shell execution
<https://phabricator.wikimedia.org/T260330> could be used for t
tstarling added a comment.
OK, I'm adding PHP execution to the service.
TASK DETAIL
https://phabricator.wikimedia.org/T240884
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: tstarling
Cc: Base, Daimona, daniel, tstarling, Bawolff, Joe, WMDE
tstarling added a comment.
I hope you don't mind if I contradict my previous comment a bit, since my
thinking is still evolving on this.
One problem with using lag as the metric is that it doesn't go negative, so
the integral will not be pulled down while the service is idle. We could
tstarling added a comment.
There's been two of these exceptions since I deployed the updated message.
They were from search rather than a diff. I wasn't able to reproduce it on the
diff page.
2020-06-11 03:13:09 [f1269b59-3ea0-4264-8c07-14ebcdd5f303] mw1413
commonswiki 1.35.0-wmf.36
tstarling added a comment.
The above exception is reproducible by going to the URL from the log entry,
or by searching Commons for p77489.
TASK DETAIL
https://phabricator.wikimedia.org/T255078
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
tstarling closed this task as a duplicate of T227266: Find out why old
revisions do not have edit links selenium test is flaky on CI.
TASK DETAIL
https://phabricator.wikimedia.org/T282674
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: tstarling
Cc
tstarling merged a task: T282674: AssertionError [ERR_ASSERTION] in item
old revisions do not have an edit link.
tstarling added subscribers: Nikerabbit, tstarling.
TASK DETAIL
https://phabricator.wikimedia.org/T227266
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
tstarling added a comment.
It's an old bug, but it seems to be failing a lot more often recently.
T227266 <https://phabricator.wikimedia.org/T227266> has a long history of it
being tweaked, skipped and unskipped. Apparently it's also flaky in production,
but that doesn't seem like a
tstarling raised the priority of this task from "Medium" to "High".
tstarling added a comment.
Looks like this test was reenabled a couple of days ago, by
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/683914 . Since
then it's been a constant nuisance,
tstarling lowered the priority of this task from "High" to "Medium".
TASK DETAIL
https://phabricator.wikimedia.org/T227266
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: tstarling
Cc: tstarling, Nikerabbit, Addshore, Pa
tstarling renamed this task from "The ApiQueryDescription should handle Chinese
language variant correctly" to "prop=description should handle Chinese language
variant correctly".
tstarling updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T26017
tstarling added a comment.
I edited the task description because the class name was incorrect. In
production this is implemented in `Wikibase\Client\Api\Description`.
I would like to know what is calling this API and whether it would be
sufficient to add a variant parameter
tstarling removed a project: Platform Engineering.
tstarling added a comment.
Yes, the RPC endpoint was added to support this use case. Use
`MediaWikiServices::getInstance()->getShellboxClientFactory()->getClient()->call()`.
TASK DETAIL
https://phabricator.wikimedia.org/T2408
tstarling added a comment.
In T285987#7191372 <https://phabricator.wikimedia.org/T285987#7191372>,
@Addshore wrote:
> Adding #platform_engineering
<https://phabricator.wikimedia.org/tag/platform_engineering/> to get some input
and thoughts on this topic from mediawiki
tstarling added a comment.
For debug output, is_resource() is often appropriate, e.g.
if ( is_resource( $item ) ) {
return '[Resource ' . get_resource_type( $item ) . ']';
}
Also, for input handling where the input may be either
tstarling added a comment.
When phan is checking for a signature match, it first checks whether the
names match:
if (!$overridden_parameter_union_type->isEqualTo($parameter_union_type) &&
That always fails in the case of an alias. Then if the target PHP version is
7.4+
tstarling added a comment.
In T308443#7931024 <https://phabricator.wikimedia.org/T308443#7931024>,
@Lucas_Werkmeister_WMDE wrote:
> The patch includes a “ResourceLoaderContext72Hack” hack class, which is
apparently supposed to work around T166010#596209
tstarling added a comment.
Basically it looks like at least a day of my time wasted debugging issues
specific to the dinosaur version of PHP we are running in production. Potential
fixes:
- Patch all affected extensions to use the new class name. The core patch
would be reapplied
tstarling added a comment.
I think my preferred solution is to combine options 1, 2: update extensions
to use the new class name, but if any affected extensions need to support old
versions of core, use @phan-suppress.
TASK DETAIL
https://phabricator.wikimedia.org/T308443
EMAIL
tstarling added a parent task: T308718: ResourceLoader namespace.
TASK DETAIL
https://phabricator.wikimedia.org/T308443
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: tstarling
Cc: Daimona, Ladsgroup, Reedy, ItamarWMDE, Michael, RhinosF1, Krinkle
tstarling added a comment.
I've uploaded updates for 35 extensions, to be merged shortly after the core
patch is merged. I linked them to T308718
<https://phabricator.wikimedia.org/T308718> so that there wouldn't be too much
bot noise here.
TASK DETAIL
https://phabricator.wikimed
tstarling added a comment.
In T306358#7885242 <https://phabricator.wikimedia.org/T306358#7885242>,
@Lucas_Werkmeister_WMDE wrote:
> `git bisect` says the first bad MediaWiki core commit is rMW1ae3b0ca8672:
Allow ContentHandler to "override" non-exist
tstarling closed this task as "Resolved".
tstarling claimed this task.
tstarling added a comment.
This is fixed in core and deployed extensions.
TASK DETAIL
https://phabricator.wikimedia.org/T260735
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailp
tstarling added a comment.
I noticed such a parse error on
https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php74-docker/9834/
:
2022-12-01 00:18:47 ff4e35fdc681 wikidb: [62aa69b10ac402af1dc9e46d]
/index.php?title=Special%3ACreateAccount ParseError: syntax error
tstarling added a comment.
Model:
'/tmp/lcstore' ] );
$store->startWrite( 'en' );
$store->set( mt_rand( 1, 10 ), mt_rand( 1, 1000 ) );
$store->finishWrite();
I ran it with
ab -n1 -c10 -v1 .../lcstore-model.php
After about 2000 successful
tstarling added subscribers: Ladsgroup, tstarling.
tstarling added a project: MediaWiki-extensions-WikibaseClient.
tstarling added a comment.
I saw this at 896198
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/896198>. The test is flaky
because the job is flaky.
InjectRCReco
tstarling added a comment.
Will the GitHub mirrors be switched over to replicate from GitLab? This is
necessary for libraries like Shellbox that use a GitHub webhook to update
Packagist.
TASK DETAIL
https://phabricator.wikimedia.org/T332953
EMAIL PREFERENCES
https
tstarling updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T332953
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: tstarling
Cc: BPirkle, Tgr, Eevans, Seddon, MSantos, kevinbazira, odimitrijevic, BTullis,
Ottomata, calbon
tstarling closed this task as "Resolved".
tstarling claimed this task.
TASK DETAIL
https://phabricator.wikimedia.org/T65015
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: tstarling
Cc: tstarling, Aklapper, Wikidata-bugs, aude, Lydia
tstarling added a comment.
In T288396#8987843 <https://phabricator.wikimedia.org/T288396#8987843>,
@hashar wrote:
> MediaWiki core has `composer run phpunit:coverage-edit` which invokes
`includes/composer/ComposerPhpunitXmlCoverageEdit.php` which looks similar to
the
tstarling added a comment.
Restricted Application added a project: Wikimedia-production-error.
LinkTitlesTest passes now. But
SetClaimTest::testAddingStatementUsingFederatedProperty fails.
TASK DETAIL
https://phabricator.wikimedia.org/T65015
EMAIL PREFERENCES
https
tstarling added a comment.
> I think core's ExtensionsTestSuite should create one suite per extension,
under a top-level extensions suite. Then CI could just run that suite, instead
of trying to guess the path.
Alternatively, you can just specify extensions/Wikibase as the p
tstarling added a comment.
It still needs a regression test.
TASK DETAIL
https://phabricator.wikimedia.org/T338213
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Lucas_Werkmeister_WMDE, tstarling
Cc: tstarling, kostajh, daniel, Aklapper
tstarling added a comment.
I don't know why mwext-phpunit-coverage is a shell script instead of being
part of quibble. Maybe @hashar can explain why it was done that way. I couldn't
find an explanation in T195918 <https://phabricator.wikimedia.org/T195918>.
TASK DETAIL
tstarling added a comment.
The way extension coverage works was not obvious to me and took a bit of time
to figure out.
- The Jenkins job `mwext-phpunit-coverage-docker-publish` runs quibble with
--commands=mwext-phpunit-coverage
- That is not an actual quibble command. Quibble
tstarling added a comment.
This happened because your talk page uses {{cite Q}}. It cites the Wikidata
item that was changed.
Wikidata item list from the edit page:
F41990390: wb dcheney.png <https://phabricator.wikimedia.org/F41990390>
Wikitext:
Might you hav
tstarling added a comment.
We (Brad Jorsch and I) didn't want random numbers in Scribunto because it
encourages an inefficient implementation of things like "spotlight" templates
that show a random featured article from a list of such articles. We want to
cache the output from
80 matches
Mail list logo
