Fri, Sep 24
Mon, Sep 20
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.
Sat, Sep 18
Fri, Sep 17
Thu, Sep 16
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?
Tue, Sep 14
Mon, Sep 13
Fri, Sep 10
and then SpecialPage::capturePath() does this:
fetching the Vector.FeatureManager service, which is initialized using the request context;
Thu, Sep 9
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?
Fri, Sep 3
Thu, Sep 2
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:
Wed, Sep 1
- Change: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/549909
- 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:
- 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
Mon, Aug 30
Pinging @hnowlan for contextual awareness.
Aug 26 2021
Sequence to do this in a backwards-compatible way, according to the stable interface policy:
- write email to wikitech-l
- introduce abstract base class with old and new method. New method is implemented based on the old, old method is abstract.
- make all exceptions that are implementing ILocalizedException extend the base class
- wait for response on email
- add new method to to the interface, soft-deprecate the old method
- change callers of old method to new method
- change exceptions to implement the new method as well as the old method
- on the base class, implement the old method based on the new, deprecate calls to the old method
- remove old method from all relevant exceptions
Aug 25 2021
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
Aug 24 2021
Aug 23 2021
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.
Aug 22 2021
Aug 19 2021
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.
Aug 18 2021
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.
Aug 17 2021
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.
Aug 16 2021
Aug 12 2021