In T284921#7363706, @Chaddy wrote:

Okay, even if there are some performance issues, let us decide ourselves if we want to live with these issues. The problems with this features affect only those who have activated it, did I understand that correctly?

In T284921#7364056, @Speravir wrote:

Another long time user of this feature here.

As it long as the current system is replaced by CSS counting I won’t complain.

In T284921#7363932, @Chaddy wrote:

Okay, so why not writing a whole new version of this feature?

I just looked at it for 15 minutes, and I can't see why this is broken, but other section titles with spaces and non-ascii chars work fine. I'll see if I can find some time to dig deeper next week.

In T284921#7363626, @Aschmidt wrote:

Thanks. But you might remember the Hitchhiker's Guide to the Galaxy and the part about the planning charts that had been on display somewhere around Alpha Centauri for some fifty earth years without anyone ever realising it? ;)

In T284917#7360584, @Chaddy wrote:

Only a few people read the tech news. It was not properly announced in the projects. And of course no one could object this when no one knew of this. You're taking the easy way out...

In T284921#7360597, @Chaddy wrote:

The option to auto-number headings is very useful. I stronly oppose any plans to remove this feature. If you want to remove it, ask the communities locally but don't decide this covertly on Phabricator.

The root cause is still unclear, filed as T291164

I assume this is no longer an issue since the introduction of UserGroupManager. Please re-open as apporpriate.

Once deployed, my understanding is the cache will still have objects serialized by the old wmf.21 code and thus contain the format property, they would thus fail to unserialize leading to the same issue. Or am I misunderstanding?

and then SpecialPage::capturePath() does this:

In T290706#7343786, @Tgr wrote:

@daniel I couldn't find the right tags but maybe this is interesting to you.

fetching the Vector.FeatureManager service, which is initialized using the request context;

Some observations off the top of my head:

• If a link update (more specifically, a RefreshLinksJob) fails, it will be re-scheduled. That would cause the event to be re-sent (but for the same page and revision ID)
• when a page gets re-parsed because a template was updated (e.g. by adding links to it), that will trigger an event with links updates that has nothing to do with the current revision ID of that page. Attributing the links update to the edit identified by rev_id is very often wrong.
• Adding links to a template will cause the same links to show up as added to all pages that use that template.
• The links go to external "authority files" (BNF, GND, LCCN, LNB are all classification systems used by libraries). Templates for external identifiers are often fed from Wikidata, so an edit on Wikidata would cause the page to be re-parsed and a links-update event to be fired. However, these identifiers are usually specific to a single page, so seeing the same update for multiple pages is surprising. Is it really the *exact* same, or does it just look kind of the same, because it's the same set of external identifiers, and most of them stay the same, and just one of them was updated?

In T284258#7330925, @Ottomata wrote:

but if it's something we want to commit to long term then we absolutely need to consider making sections a Real Thing inside MediaWiki

Hm, I disagree. Sometimes it will be necessary to have 'materialized views' of data inside outside of the monolith in separate places. Wikidata Query Service is a great example (and the basic event driven architecture is similar to what is proposed for this Knowledge Store, IIUC). It runs a transformed view of Wikibase context to serve a different query model. Building everything in MediaWiki isn't going to scale (performance-wise and people-wise). We should make it is easier for more products (that are transformed materialized views of MW data) to be built outside of MediaWiki.

I made this doodle of an "event driven mediawiki" architecture a while ago. I had forgotten about this, but listening the "db inside out talk" made me remember. I'd be curious to hear in how far this matches other people's ideas:
https://lucid.app/documents/view/c5edd03c-677e-4e24-a7e2-d0aedbc73280

• Change: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/549909
• Summary:
  • This moves the code that handles page protection out of the Title class. It's a complex refactoring or critical functionality, and the code is hit on pretty much every request, in order to perform permission checks.
• Test plan:
  • We improved phpunit test coverage of the old code and ensured good coverage of the new code. We also wrote extensive end-to-end tests to ensure that page protection still works as expected.
• Places to monitor:
  • It is hard to ferosee what kind of issue would be cause by this. We were very careful not to break things, but we may still see errors due to e.g. type hints that have become more strict, or performance issues if we got the caching wrong somewhere. We may also see unintended changes in user facing behavior. All of these seem unlikely, but you never know.
  • Logstash: mediawiki-errors
  • Grafana: mediawiki-errors
• Revert plan:
  • Identify and fix specific issue
  • Revert patch. This does not touch many files, we might see some conflicts in Title though. Note that the relevant code reads and writes to WanObjectCache. The structure of cache entries should be forward and backwards compatible.
  • If all fails, rollback train.
• Affected wikis:
  • all
• IRC contact: Duesen, Pchelolo. But better find Daniel or Petr on the platform-engineering slack channel.
• UBN Task Projects/tags: Platform Team Workboards (MW Expedition) Platform Engineering

Pinging @hnowlan for contextual awareness.

In T272424#7317272, @Daimona wrote:

Is this task still blocked?

In T263166#7312731, @dduvall wrote:

In T263166#7300889, @daniel wrote:

The base layer would be per-site configuration. This can be pre-generated for each wiki, and be copied or mounted into the mediawiki containers. This rarely changes.

To clarify, when you say "into the containers" do you mean the container images or at runtime via a k8s volume (sourced from a configmap or otherwise)?

Sequence to do this in a backwards-compatible way, according to the stable interface policy:

1. write email to wikitech-l
2. introduce abstract base class with old and new method. New method is implemented based on the old, old method is abstract.
3. make all exceptions that are implementing ILocalizedException extend the base class
4. wait for response on email
5. add new method to to the interface, soft-deprecate the old method
6. change callers of old method to new method
7. change exceptions to implement the new method as well as the old method
8. on the base class, implement the old method based on the new, deprecate calls to the old method
9. remove old method from all relevant exceptions

Educated guess based on a quick look at the code: In NotificationAlertComponent line 63, 'title' => $notificationAlert['text']->text() needs to be replaced by 'title' => $notificationAlert['text'].

Still happening, wasn't the fix supposed to be in 1.37.0-wmf.19?

tagging for code jam

In T289351#7306214, @sbassett wrote:

Not that this needs to be a security patch (it can go through gerrit) but this should fix the immediate issue of better handling the non-object error. Tested fine locally against master (89259d5a61):

Based on my limited understanding of Kubernetes, I could imagine a multi-layered configuration system, where one layer can override the other. I'd be interested to hear if I'm at all thinking in the right direction with this.

In T288707#7295246, @dpifke wrote:

If you don't mind, we'd like to keep this issue on our radar. We use that tag for tracking performance-related issues, even if another team is working on them.

This error was caused by the introduction of ActionFactory.

Dropping the priority from UBN to "high" after re-assessing the impact: This error only occurs when attempting to apply an action that is defined to a page that it is not applicable to. The action still works as expected if used as intended, and we will only attempt to instantiate classes that have a name that match a defined action, not arbitrary classes.

Flagged as UBN until we can confirm that this does not break Flow in a critical way, and does not pose a security risk.

In T289014#7292663, @tchin wrote:

I think the easiest thing to do for now is to implement Tim's previous solution to this since it's throwing at the same logical spot, but this time for archived rows

So, Flow injects fake rows into the contribs pager. These fake rows are *not* instances of stdClass (which is the class of anonymous objects only). Flow has a hierarchy of classes it uses for fake contributions rows, with FormatterRow as the base class.

The way Flow injects fake rows into the contribs pager is quite horrid, but pretty much impossible to fix. It's a direct consequence of the fact that flow implements its own revision storage instead of using core's.

It may be useful to make UserRIghtsProxy implement UserIdentity. This way, we can just start passing $user to UserGroupManager without worrying about whether it's a User or a UserRightsProxy. Then we can make the constructor of UserrightsProxy emit deprecation warnings.

I agree: keep using WikiPage::prepareContentForEdit() until Id5ba40a21 lands, then start using that. Feedback on that patch would be appreciated.

The second part doesn't seem to make much sense, and talking with @daniel we agreed that it looks more like a bug than a feature. Fixing this not only requires a code change, but also a maintenance script to set page_is_new back to 0 for pages with more than one revision.

In T284258#7279121, @dmontalion wrote:

Rather than a product, I would say a platform, or an abstraction layer, needs a data model. But this may be semantics. (Personal side note: in yesterday's Enterprise discussion, this would refer to the WME stream specifically.) The platform/layer protects us from needing One Ultimate Standard because it maps data from sources (a wiki, ORES, a 3rd party, wikidata) to a standard. Consumers can consume it ... but the source data is also still available, as it is, where it is.

Per above.

In T284258#7277278, @Mooeypoo wrote:

It does not describe changes to our current underlying systems, databases, or event schemas; it describes an overlay layer for systems that are directly meant for distribution, rather than strictly editing within the context of MediaWiki.