User Details
- User Since
- Oct 4 2016, 5:18 PM (388 w, 6 d)
- Availability
- Available
- LDAP User
- Pmiazga
- MediaWiki User
- PMiazga (WMF) [ Global Accounts ]
Fri, Mar 15
@Tgr In ExternalStoreDB::initializeTable() we were passing QUERY_IGNORE_DBO_TRX only, which anyway was incorrect - the schema initialization code should pass QUERY_CHANGE_SCHEMA which is also a flag that isWriteQuery() would consider.
@Tgr Now, if flag doesn't match one of SQLPlatform::QUERY_CHANGE_NONE, SQLPlatform::QUERY_CHANGE_TRX, SQLPlatform::QUERY_CHANGE_LOCKS. SQLPlatform::QUERY_CHANGE_ROWS , SQLPlatform::QUERY_CHANGE_SCHEMA, SQLPlatform::QUERY_PSEUDO_PERMANENT - we throw exception,
Thu, Mar 14
@aaron @Ladsgroup could you advise on what to do here? The ExternalStoreDBcalls $dbw->query() with QUERY_IGNORE_DBO_TRX -
Recreating a new wiki from scratch fails with:
Tue, Mar 12
Mon, Mar 11
@Bmueller please check if we could fit that into next fiscal year.
Note: [Wikitech-l] MediaWiki 1.42-alpha will be branched as a beta on 9 April 2024
Wed, Mar 6
Tue, Feb 27
Mon, Feb 26
@RoySmith - the Thursday issue we're trying to fix is not related to this issue. We encountered a DB replication issues that affect only Beta Cluster wikis - not production one.
@kostajh nope, we didn't do --skip-clusters. On first run it failed with missing migration, we fixed the script and we executed it again - but on the second execution it couldn't go through - so we dropped the test2wiki on beta cluster db (db11).
@hashar yes, I dropped the database as addWiki.php script created a partially created schema (script failed in the middle of run), re-running script caused it to fail again as some tables were already created.
Fri, Feb 23
I left the script working for 15 minutes and looks like it's slowly progressing:
So I executed the script by hand and it looks like it gets stuck.
This job runs the`wmf-beta-update-databases.py` script - I wonder if I can run it manually and see the output. I compared the last sucessfull run and first failed runs:
T358236 could cause this issue as the addWiki.php script failed in the middle of the process and I had to drop the test2wiki multiple times manually (as the script was failing due to multiple reasons, I fixed those one by one). Those things happened around similar time.
Thu, Feb 22
After all fixes now script still fails, but this time on something new - which I think may be a result of running and dropping addWiki.php script multiple times.
I just checked logs, still happening - 177 instances in last 6 hours.
@Urbanecm_WMF thanks for the point - that's helpful. I checked the addWiki script for all remaining SQL files and looks like they are on the right place. I'm going to submit another PR to fix the Linter SQL file location and then hopefully it's gonna work.
@bd808 in Linter script was moved to sql/mysql folder to match how we have it in other extensions
For tracking purposes - the Linter extension had the SQL files moved recently (see https://phabricator.wikimedia.org/T353922, change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Linter/+/985070).
After updating the Add Wiki script - I was able to run the script - but it kept failing due to partially created DB. Previous run already created some tables so I had to manually drop the database.
@Physikerwelt thanks for joining the conversation. I quickly created the ticket so I don't forget and started investigating this issue. We found out that those changes were intentional and we should update the add wiki script.
As a quick solution, I think we could bring the SQL files that were removed in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/975432
Cannot move forward due to Mathoid/BetaCluster problem - https://phabricator.wikimedia.org/T358236 - the AddWiki script fails with missing SQL files for Mathoid extension. I'm looking into that.
Wed, Feb 21
I spoke with @Urbanecm_WMF about creating new wikis and I learned that we want to keep the beta cluster wikis similar to production wikis. In other words, if we want to create a wiki then it should be something that is not available on the beta cluster yet but has a production equivalent. It is not desirable to have beta-wikis that do not have a production equivalent.
Mon, Feb 19
MediaWiki Core Special Pages provide two helper methods requireLogin and requireNamedUser. Those methods check user type and redirect to UserLogin in case we have a user with the wrong type.
Feb 13 2024
I would stick to beta.wmcloud.org as it nicely sticks follows {LANG}.{PROJECT}.org schema. Now I wonder, do we need an additional domain too?
Feb 12 2024
Looks like we already have a pretty similar error message
I'm going to start adding items that needs to be done. @taavi you mentioned that beta.wmcloud.org is already designated for this. But do you meant that we can create a wiki with beta.wmcloud.org URL, or are we talking about creating a subdomain under beta.wmcloud.org ?
Feb 8 2024
After checking https://www.mediawiki.org/wiki/User_account_types - Temporary Users feature set is more aligned with Anon user, not registered. The only difference between IP and Temp is that Temp can receive notifications -> which if I'm right was already happening for edits coming from IP - therefore it's not anything new.
Feb 5 2024
Jan 29 2024
Looks like this feature is already partially implemented. If you check the UserMailer class we already send the List-Unsubscribe header:
Jan 26 2024
The only thing I would consider at this stage is to see if we want to show identical error messages to temporary users and anons.
Jan 24 2024
Existing OAuth logic already expects users to at least have email defined. Some parts of the system go a little bit further and require a confirmed email. Temporary accounts cannot log in as those do not have passwords - further more - they cannot update their email which already prevents them from using OAuth.
I tried to make a stab at this work some time ago (patches that Krinkle mentioned ) but then I abandoned the idea. Now I want to get this thing done and noticed you made a ticket for it and pushed a PR. Nice. Thanks.
Jan 23 2024
Jan 17 2024
In the OATHAuth extension we are required to change two places:
The WebAuthn extension requires one change to fully support IPMasking. The only place that required investigation is checkPermissions method - https://gerrit.wikimedia.org/g/mediawiki/extensions/WebAuthn/+/122deaa8a99b868c08f9fa1e5e5d4ab0a4387bf3/src/Api/WebAuthn.php#112
Jan 15 2024
Jan 8 2024
Jan 5 2024
Dec 15 2023
@Krinkle do you have any thoughts on this? Do you know where the Wikimedia/LightweightObjectStore comes from?