In T212482#5211044, @Krinkle wrote:

@daniel Given a filter only mutating one value (previously written as "taking one parameter", we since then loosened it up to allow any number of parameters, but only one of which should be mutated by the hook), this could also be solved by using the return value.

This seems to be done

SlotRoleRegistry (rMW023fec5d7b3a1a4b57d7bd3c555eeb06fd6bae22) already uses the registry-as-a-lazy-factory-with-DI approach: it gets a bunch of callables injected. For REST Router it seems we are going to use a similar approach, with injecting the name of a JSON file which contains object declarations for use with ObjectFactory.

In T221177#5210318, @Tgr wrote:

In T221177#5210268, @daniel wrote:

Can we agree for now that the rest routing should live in libs OR a separate repo, and nothing under the Wikimedia/REST namespace (or whatever we may end up using) should depend on anything that is not itself a library (either a real composer component, or a pseudo-library in libs)?

There is no harm in putting it in libs, and IMO we should be conscious about dependencies and avoid them were possible, but if using Message or Hooks seems to be the sane thing somewhere, I don't think we should go out of our way to avoid it just because those haven't been librarized yet.

So, we have a potential fix, but it doesn't seem to work with wikibase? Does the wikidata team know?

Maybe this will fix the issue? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/497537

@Tgr I see your point, and I share your concern about the annoying procedures for a version bump.

I like @Anomie's proposal a lot. Some minor points:

In T224224#5209764, @Nikerabbit wrote:

Here be dragons indeed. It's very hard to know what will eventually rely on a session. For example I have seen the same error in ResourceLoaderProjectIconsModule which works fine, until a file it references is not found, in which case code deep in the trace is trying to generate error messages... in user language.

In this case any hook which would have caused the $userLang parameter to unstub would have caused this. It just happens always and consistently now.

The session took place.

Follow-ups:

• T223723: Ruprecht: measure inverse transitive reach
• T223724: Ruprecht: measure LoC in tangels.
• T223726: Ruprecht: Investigate filtering dependencies by Connascence
• T224107: Ruprecht: investigate visualization of dependency graph

In T202094#5209537, @tstarling wrote:

@daniel asked me about this, following a complaint in CR from @Simetrical that the function was deprecated despite its usage not having significantly changed since it was introduced, without apparent awareness of what it is for. The idea is that if you have a remote file repository hosted on a wiki with $wgCapitalLinks=false, or a remote file repository that is not a MediaWiki instance, then [[File:foo.jpg]] and [[File:Foo.jpg]] may refer to two different files. So to know which one was intended, you have to get the link text before it was mangled by ucfirst().

In T212521#5101368, @Jdlrobson wrote:

If moving the integration tests out of QUnit means moving them to Selenium, then I'm not in favor if this RFC as is,

The proposal is to keep the existing setup, but migrate tests which are not actually needed as integration tests to a quicker isolated build.

My personal take is that it would be silly to forbid global classes from being imported via use, thus requiring the leading backslash.

In T224095#5206473, @gerritbot wrote:

Change 511979 had a related patch set uploaded (by Daniel Kinzler; owner: Daniel Kinzler):
[mediawiki/core@master] Make userLink() not fail too hard on false and null.

https://gerrit.wikimedia.org/r/511979

Pinging @matthiasmullie, because he last touched the relevant code in Flow.

This is not the same as T222628, which is about a problem in Linker::formatAutocomments. This here is about a problem with Linker::userLink, which needs a different fix. Both were triggered by the same change, b6e1e99bec8d -- but while the code in formatAutocomments was actually wrong, the problem here seems to be different. The error is triggered in line 915 of Linker, which has:

In T222628#5204429, @hashar wrote:

There are various code path from extensions or mediawiki/core that ends up hitting the error. It has been added in mediawiki/core by https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/504000/

This looks similar at a glance: T221577: Wikimedia\Rdbms\LBFactory::getEmptyTransactionTicket: GeoData\Hooks::doLinksUpdate does not have outer scope

Hm, my experimental patch makes CI tests time out. I must have broken something, but I really don't see what. Running the "relevant" tests locally, everything seems to be doing fine.

In T222907#5171149, @Eevans wrote:

FYI, I think CentralAuth needs a TTL different to that of regular sessions (IIRC, this was cited as a reason for exposing the TTL). Regardless of whether or not this is true, we should probably consider using a different instance of the service for CentralAuth (it's trivial to do). If we do, we can configure it with a different default TTL as well.

Flagging for re-triage in the CPT team. I personally don't know where to start with investigating this, but perhaps @amonie or @tstarling would know. The performance team has a lot of log wrangling expertise, so perhaps we could team up for the investigation.

In T221177#5198258, @mobrovac wrote:

This was perhaps discussed elsewhere (and I'm simply not aware of it), but the ticket and its discussion seem to be based on the (unspoken) assumption that modules/extensions have to be able to register their own REST API paths and end points independently, much in the way the Action API currently works.

That's because they do, unless you're wanting to force every site administrator to configure the router endpoints manually for every extension they install.

In T212129#5199079, @Krinkle wrote:

Expectations of MediaWiki 'Main stash' are (as documented in ObjectCache.php):

• Stored in primary DC.
• Replicated to other DCs.

In T220493#5198263, @ArielGlenn wrote:

@daniel Any new information that we'll have for slots/content that we need to include, besides length, content model/stuff, and sha1?

In T220493#5191025, @ArielGlenn wrote:

@Anomie while you're here, do you know if there are further plans to move fields out of the revision table in the short/near term or otherwise to refactor its schema?

Please have a look at the WIP patch linked above. My approach there is to join in the slots and content tables directly instead of doing a second query for each batch to fetch them. The code would not have to change much to adopt that approach, though.

In T223447#5198110, @Daimona wrote:

Have you seen T187153? If it's the same issue (and I think it is), mRecord is null because there's a Revision object serialized and stuffed into the DB which could be 10 years old now, it's pretty obvious that unserializing and using it is not going to work...

In T223447#5197319, @hashar wrote:

And mRecord is null somehow :-(

In T223099#5195113, @TK-999 wrote:

In the current state, memcache entries for User instances include their configured preferences as an array. Should this be kept for B/C during the refactor?

ping @zeljkofilipin: you are already on the other relevant tickets and also on the spreadsheet, but I though you may want to have a look at the test file example here.

In T221177#5188930, @tstarling wrote:

I think it would be necessary to:

• Introduce and libraryize a new interface for BagOStuff

Conversation copied from Gerrit, to be continued here:

Tagging Core Platform Team for triage.

See T222409: Standardize declarative object construction in MediaWiki for a discussion of a generalized mechanism for allowing dependency injection when creating objects from some kind of non-code specification, as may be provided via extension.json.

One thing that we could add would be a convenience function that allows the caller to assert that the return value actually has the correct type.

I like this proposal a lot. I can't find anything missing, either.

In T222827#5181597, @Rfarrand wrote:

Hi @daniel can you provide some links, background & current issues being work on for the TechCom?

Maybe I'm naive, but I'm wondering why any jobs need to be involved at all. Shouldn't be deleting all items for a given user be a split second operation on the db table? Can anyone shed some light on why this is slow enough to require cascading jobs

Re-opening, extensions still need to be fixed.

Disengaging for lack of consensus. It seems the focus/purpse of this ticket shifted a lot, so at least the task decsiption should be changed.

How frequent is this? Should it be high priority?

Unassigning myself, since I don't know what do to about this. I'm probably not the best person to investigate this issue, either.