The feedback loop work ended in June. It looks like we cut the pipeline feedback time by half (Feb -> June). What we could do to cut the time even more would be to remove the SQLLite job or fix the problem with the problem running tests T427349.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Today
I am going to close this as resolved for now. If we run into more instances of this, we will have more useful info to debug this based. As it stands now, it is not debuggable.
Mentioned in SAL (#wikimedia-operations) [2026-07-14T03:39:10Z] <mwpresync@deploy2003> Finished scap sync-world: testwikis to 1.47.0-wmf.11 refs T430830 (duration: 36m 01s)
Waiting on the change to get merged.
Change #1310240 had a related patch set uploaded (by Eileen; author: Eileen):
[wikimedia/fundraising/SmashPig@master] Chariot refactor - pass donationObject a little more & donation array a little less
For trwiki, I left a note on https://tr.wikipedia.org/wiki/%C5%9Eablon_tart%C4%B1%C5%9Fma:GBM about pages that need fixing. So, nothing for us to do here.
We had similar tasks for performance test in the past where we wanted to test critical user journeys (see for example T373172 T321711 and more). The problem those times was not technical: it was really hard to get product to define the journeys. I think we should start there, get top 5 (or ten) journeys.
Change #1310239 had a related patch set uploaded (by Eileen; author: Eileen):
[wikimedia/fundraising/SmashPig@master] Chariot: switch to later helper for amount for file
Change #1309168 merged by jenkins-bot:
[mediawiki/extensions/UniversalLanguageSelector@master] ULS rewrite: add keyboard navigation test spec
Mentioned in SAL (#wikimedia-operations) [2026-07-14T03:03:08Z] <mwpresync@deploy2003> Started scap sync-world: testwikis to 1.47.0-wmf.11 refs T430830
Change #1310237 merged by jenkins-bot:
[operations/mediawiki-config@master] testwikis to 1.47.0-wmf.11
@happy5214 @TheDJ The deployed patch did not help with this issue, yet causing new issues (T296396#12117120 and T431919).
Change #1310237 had a related patch set uploaded (by TrainBranchBot; author: MediaWiki PreSync):
[operations/mediawiki-config@master] testwikis to 1.47.0-wmf.11
Change #1310236 had a related patch set uploaded (by Eileen; author: Eileen):
[wikimedia/fundraising/SmashPig@master] Chariot: minor refactor Move functions to depositObject
Change #1310233 had a related patch set uploaded (by Bhsd; author: Bhsd):
[mediawiki/extensions/CodeMirror@master] CodeMirrorMediawiki: Parsoid errors
The root cause is that REST API returns invalid results.
- Week 6 Weekly Report
Change #1310231 had a related patch set uploaded (by Bartosz Dziewoński; author: OAuth Developer):
[mediawiki/extensions/OAuth@master] Introduce ConsumerAcceptanceRepository service
Maybe UpdateNumberOfArticles will be the right place to clear the scrollbar.
We can instead hide all closed wikis by default (but still allow users to display them).
I reviewed all uses of ->info() and ->warning() for logging (which are the only log levels I see logged in production), and all uses of new MWOAuthException, and added consistent log context to them (using a new method on Consumer) whenever we have a Consumer object already available or can easily fetch it. I think this is thorough enough that we'll be able to confidently close this task.
-- 1. silverpop_export_stat: both per-fund highest columns are gone entirely -- (the single-column index on endowment_highest_usd_amount drops with its column) ALTER TABLE silverpop_export_stat DROP COLUMN foundation_highest_usd_amount, DROP COLUMN endowment_highest_usd_amount;
Change #1309312 merged by jenkins-bot:
[wikimedia/fundraising/tools@master] Ensure years_consecutive is 0 if no value
Change #1309289 merged by jenkins-bot:
[wikimedia/fundraising/tools@master] Add previous segment & change date to Acoustic export
Change #1310227 had a related patch set uploaded (by Lars SG; author: Lars SG):
[wikimedia/fundraising/tools@master] Remove unneeded separate endowment & foundation fields
An amazing outcome would be to treat compositions in AW not as single calls. Instead gradually resolve them from the inside out, caching along the way, and giving each new level its full time allocation. Then could safely switch to back to paragraph from sentence.
raymond-ndibe updated https://gitlab.wikimedia.org/repos/cloud/toolforge/jobs-cli/-/merge_requests/143
Change #1310226 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[mediawiki/extensions/OAuth@master] Make MWOAuthException log consistent consumer info
Change #1310226 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[mediawiki/extensions/OAuth@master] Make MWOAuthException log consistent consumer info
Change #1310224 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[mediawiki/extensions/OAuth@master] Update all ->info() and ->warning() calls with consistent consumer info
Change #1310224 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[mediawiki/extensions/OAuth@master] Update all ->info() and ->warning() calls with consistent consumer info
raymond-ndibe updated https://gitlab.wikimedia.org/repos/cloud/toolforge/jobs-api/-/merge_requests/264
jobs-api: bump to 0.0.540-20260714004554-38eaaabf
Started the backfill.
Change #1308180 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[mediawiki/extensions/OAuth@master] SessionProvider: Add consumer info to log context when using OAuth
Change #1310219 merged by jenkins-bot:
[mediawiki/core@wmf/1.47.0-wmf.11] Branch commit for wmf/1.47.0-wmf.11
Change #1310219 had a related patch set uploaded (by TrainBranchBot; author: trainbranchbot):
[mediawiki/core@wmf/1.47.0-wmf.11] Branch commit for wmf/1.47.0-wmf.11
Change #1310217 had a related patch set uploaded (by Lars SG; author: Lars SG):
[wikimedia/fundraising/crm@master] Remove unneeded separate endowment & foundation fields
group_203_bot_3c0afd0d9fd9529f3b7bc7e69a4a3bce opened https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/merge_requests/1335
@HCoplin-WMF The /discovery endpoint is indeed exactly what I was looking for. Feel free to close this as resolved.
k8s/jobs.py: set PORT env whenever a job exposes a port
jobs-api: bump to 0.0.539-20260713213805-22bde880
Looks good on 50598-r-2026-07-13
Tested on:
Pixel 6 on Android 16
Pixel 8 on Android 16
OnePlus 8 on Android 13
Galaxy A36 on Android 15
Ah, the druid_analytics point is good context, I wasn't aware of that.
What is the status of this? The clock has now been smashed; /8 now fails to transclude due to PEIS limits.
Change #1310215 had a related patch set uploaded (by Pwangai; author: Pwangai):
[wikimedia/discovery/discovery-maven-tool-configs@master] Fix sonar authentication
Change #1310214 had a related patch set uploaded (by Pwangai; author: Pwangai):
[research/mwaddlink@main] Fix sonar authentication
Change #1310212 had a related patch set uploaded (by Raymond Ndibe; author: Raymond Ndibe):
[operations/docker-images/toollabs-images@master] webservice-runner: default to 8000 only if PORT and TOOL_WEB_PORT has no value
In T310456#12115992, @Ladsgroup wrote:In T310456#12113246, @Jonesey95 wrote:In T310456#12113083, @Ladsgroup wrote:In T310456#12112811, @Jonesey95 wrote:Has this task been addressed? Even if reports take a while to update, it is useful to have them updated daily in order to detect vandalism and other inappropriate edits.
Hi, can you tell me which reports help you detect vandalism?
Any of the above reports, and many more, when they are updated frequently and thus able to be monitored and kept clean regularly, can indicate vandalism. Vandals and careless editors remove categories, leaving pages uncategorized. They remove links, leaving pages as dead ends. They remove valid transclusions of templates, leaving templates on a "not transcluded" report. You name it, vandals do it, and one purpose of pretty much every error-tracking category and report is keeping an eye on vandalism and being able to revert it quickly. When a report is refreshed only monthly or semi-monthly, that job gets much more difficult, and vandalized pages are visible to the world for much longer.
Here's an example: This careless edit removed the documentation from a template, which caused the page to appear on a report of templates with no categories. Because we keep that report clean and it refreshes daily, the careless edit was easy to fix before it was seen by many people, and before it was amended or "fixed" in some unhelpful way.
In this example, which report would have reflected that? The problem is that I need to know which one of these reports are higher priority and which ones can be done semi-regularly.
Change #1310211 had a related patch set uploaded (by Pwangai; author: Pwangai):
[mediawiki/services/push-notifications@master] Fix sonar authentication