As for the issue reported in this task, it's been resolved. In theory, it will always be

Use register_shutdown_function?

teardown (theoretically at least). But in any case, maybe you could use a test listener (https://phpunit.de/manual/6.5/en/extending-phpunit.html#extending-phpunit.PHPUnit_Framework_TestListener) and implement endTestSuite() ? It's not exactly identical since there are generally multiple suites being executed at once, but I think it might meet your needs.

... and by that you mean "MediaWikiServices::getInstance()->resetServiceForTesting( 'NameTableStoreFactory' );" ?

tests but the table (change_tag) got emptied. Do you do something similar in the tests?

@Ladsgroup I believe this is caused by one of your changes.

The issue is still pending with 1.31 but somehow I get the feeling no one really cares since it has been open for one month without any feedback.

They shouldn't do that.

I'm not sure what you mean, as extensions aren't supposed to be adding things to core's composer.json.

From my POV the script is working as it is expected to

We don't close bugs just because they are inactive.

Closing due to inactivity (1y+) since it cannot be expected that anything will be done within a reasonable amount of time.

I would please ask that you don't try and put words in my mouth.

please let me know instead of ranting on random tickets (it's mostly coincidence that I saw this on IRC).

[mediawiki/core@master] MCR database schema
https://gerrit.wikimedia.org/r/378724

GraphViz no longer working ...

The SRF devs seem dead against supporting extension registration

@cicalese @MarkAHershberger FYI

[mediawiki/core@master] [MCR] Add optional $title param to Revision byId methods
https://gerrit.wikimedia.org/r/399795

No. You could check this for yourself very easily

@Reedy Do you think your response in tone is appropriate? I don't think so!

T104954: ExtensionRegistry / wgExtensionFunctions not treated as array?, SemanticMediaWiki needs to stop registering its hooks in a $wgExtensionFunctions, which is too late. +cc @mwjames.

@Kghbln FYI

From my POV the script is working as it is expected to - we only used fixed versions in MediaWiki core's composer.json

@Tgr Please can you acknowledge the https://phabricator.wikimedia.org/T87572#3306652 comment from 1 Jul? I do hate it when I waste my time while being on phab and people do not respond!

Do we need to advertise composer.local.json more prominently in documentation? e.g. in

that was @demon in T92503: Remove EOL MediaWiki release branches i believe.

@Legoktm If time permits please comment on the outlined issue.

I'm no longer expecting any response or help from a MW developer on the stated issue but for those who face a similar problem, I added a suggestion that may work for them and is what I understand as community support.

An idea, discussed at SMWCon Fall 2017, is to have a mechanism to directly serve the content of static sources (i.e. files) bundled with an extension.

My understanding is that once MediaWiki complies with (not sure that is the correct terminology) PSR-4, that community will be willing/able to adapt to extension registration.

No reply. Hence assuming yes.

The confusing part here is that Database is logging the internally caught non-error into the debug channel for debugging purposes.

This is more of a status report on running PHPUnit 6.x/PHP 7.1 with MediaWiki since I needed to modify core in order for our tests to pass. Whether the provided information are of interest or value to developers I don't know, I just wanted to disseminate our experience on the related matter.

the log file writes are introducing a slight performance hit (not to mention it makes it harder to find actual errors in them)

ERROR: duplicate key value violates unique constraint "md_module_skin"

A quick checkout of the PR confirms that the system no longer produces above listed exceptions.

You know how to mark bugs as release blockers, so if there's a regression you've found and want to see it fixed, mark it as a release blocker. :)

Do we think that this is going to be fixed in 1.30, given that it has a valid exception stack trace?

I was patiently awaiting (two weeks+) this issue to be triaged since this is clearly a regression since 1.29!

I reckoned there was a similar issue [0] in the past and I would have expected that a unit test is in place that would prevent such a regression.

So, what is the status of this patch, issue?

I don't think there is an established convention and most extensions actually just use <extensionname> but IMO using MediaWiki\Extensions\... follows from the PSR-4 recommendation that namespaces

do you want some time to do an announcement/anything of that nature first?

since that page disables the OutputPage for some commands and does not set a cache-control header, if this is used in an environment where autocreation can happen, an attacker might be able to cause an admin's session id to be cached

See https://github.com/search?q=org%3ASemanticMediaWiki+getTalkPage+&type=Code

@Legoktm It would be marvellous if could take a peek at this.

On what url did this happen?

Did that not work?

... rc.1 has been released like 10 minutes ago, but it'll make it into the final release.

In which case, I suggest those driving the patch press the cherry-pick button and get a patch up for review on the target branch.

All blockers are now resolved.

With reference to https://gerrit.wikimedia.org/r/363727 and the comment "... should fix warnings about TransactionProfiler in objectcache...", it does NOT as it can be seen from the log output:

This was adopted in fda4d46fc4f810, ...
https://gerrit.wikimedia.org/r/363727

This isn't just PostgreSQL, it applies to MySQL too.

... specific to PostgreSQL, but after failing to reproduce the premise, Aaron pointed out "pg" in the wiki name.

Which tests specifically fail for you?

Doing a quick var_dump on $encLike = $this->escapeLikeInternal( $table, '\\' ); reveals that before the PR it would return "unittest\_archive" and now after the change it contains "unittest\_unittest\_archive".

This change just broke all of our integration tests with:

@Seb35 Maybe something you want to have look at a convenient time?

So this is probably some incompatibliity with Semantic Glossary and SMW 2.5?

@demon FYI

I think the method of injecting TransactionProfilers needs refactoring to make this more flexible, and given that this warning is mainly intended for developers I don't think it should be a release blocker (since it's not trivial to fix).

Normally, I would use redis but this time around for testing I just used the vanilla setup that comes with SqlBagOStuff out of the box hence the increased log output.

or the cost of writing to a file on the server-side?

Also nothing is thrown here, there is no PHP "exception". Rather it's a debug log message (severity=INFO) that is hidden by default and (for easier debugging) includes a manually created stack trace.

@mwjames can you confirm that everything here works now please?

I was able to confirm that this fixes the reported issue and I'm able to run our integration tests without major interruptions.

@Krinkle As for the last stack trace, it happens on each edit and causes a significant lag during a save action.