I have been having this issue in sdzerobot tool. After many months of trouble with the node-redis client, I moved to ioredis thinking it's a client issue. But the issue persists. It appears the client sometimes spends 15+ minutes trying to reconnect after a connection loss.

In T367415#9917616, @fnegri wrote:

Maybe wiki_uid in the user table is potentially sensitive? It seems to be the Mediawiki id for the user, I'm not sure if we should expose it.

Gadgets extension no longer adds any namespaces.

Gadgets extension no longer adds any namespaces.

https://patchdemo.wmflabs.org/wikis/66b1838f1a/wiki/Main_Page and https://patchdemo.wmflabs.org/wikis/66b1838f1a/wiki/MediaWiki:Gadget-abc.js show this working.

This can be done now using the new categories option. The interface messages on top of change list pages (watchlist-summary, recentchanges-summary, recentchangeslinked-summary, histlegend) can be customised to include the category.

The EXPLAIN capability is back up now!

It's surprising that this issue still occurs with pre-ping enabled – Trove connections from the pool are now validated to ensure liveness before being used. Perhaps I don't understand SQLAlchemy well enough... Also, even with Trove errors occurring, the fix from T365136 should have caused them to show up as a failure in the UI. Both fixes not working makes me wonder if there's a problem with the deployment. The updated files are visible in the pod, though.

In T367464#9896220, @Novem_Linguae wrote:

In T367464#9896165, @Liz wrote:

Now, there is a little grey box saying "Explain" at the bottom of the page under Query Status (see this Quarry query ) that just produces a table of code I don't understand and isn't helpful at all, at least to me.

That's probably unrelated to this ticket. Is probably a recently added feature.

https://github.com/toolforge/quarry/pull/22/ was merged last year.

The fix is live. Please reopen if the problem arises again.

The fix is live. Please reopen if this occurs again.

Or more likely because of a connection reset from Trove (T367464).

The actual problem should be sorted with the fix for T367464.

One such case: https://quarry.wmcloud.org/query/83084

In T334372#9890545, @Bawolff wrote:

I would suggest making this an extension. I think this would be a very hard sell as a mw core feature. (Of course, being realistic, its still going to be a hard sell getting the extension deployed to WMF)

In T334372#9889153, @PatchDemoBot wrote:

Test wiki created on Patch demo by SD0001 using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/d1a455521c/w

Have raised the basic WIP patch which embeds the rasterized PNG as a base64 blob in a data:image URL. I could use some help in figuring out how to store the png in the file repo and have the parser generate just a link to that.

This is because of redis pod getting restarted. It'll also happen during deployments. Ideally, we should configure RDB or AOF persistence for it.

https://github.com/toolforge/quarry/pull/48

No, but the PR fixes the UI so that the actual error shows up.

To implement this, we can record the start time as another attribute in the extra_info JSON blob in query_run table when the query status is set to running, and use JS client-side to start a counter. On page reload, the counter can be initialised to the value based on the start time in db.

This could be because of a worker going down.

I'm not sure either about how to deploy in the new k8s-based setup. However, /home/rook/quarry seems to be the git checkout referenced above.

In T365374#9880226, @SD0001 wrote:

But this doesn't explain why the issue occurs when querying the wiki replicas.

Ah well, looks like the deployment of https://github.com/toolforge/quarry/pull/40 didn't fully go through. The keys TOOLS_DB_USER and TOOLS_DB_PASSWORD are missing in config.yaml on the pods, although I could have sworn this wasn't the case the last time around when I looked into it.

Many failures from today. (Could it be a coincidence that it's occurring only on the days someone is trying to test T348407?)

In T241524#9873840, @Tgr wrote:

The cache purge probably just requires queueing a links update job with the right parameters; I think that would be the same with a parser function (which would presumably be tracked in the templatelinks table).

In T204201#9877960, @Od1n wrote:

Another issue: I have a case with a gadget ("Diaporama" here) that is defined with a "categories" condition, but this gadget may also be loaded using mw.loader.load()/ mw.loader.using() (by this script), on a page that does not have the category.

I don't think this should be closed just yet. This is still the "more correct" approach. The categories stuff is just a hack to avoid introducing new wikitext.

In T204201#9861245, @Od1n wrote:

About the conditional loading based on categories: If we edit a section (instead of the entire page) and the category wikicode is outside the section, will the gadget be loaded, or not?

This is same as T53443: Replace "Chosen" jQuery plugin.

This should already be possible. The gadget description messages which are used in preferences support full wikitext.

GET endpoints are more user-friendly as you can hit them on a browser - which can be a way to show an inference result to a non-technical user to explain why a bot or tool behaves the way it does.

I am open to adding logging, but I think we should only log the sender and receiver, and maybe the header. Logging the content kills the point - the bot might as well just send a talk page message. Instead, I suggest we provide a "Report spam" button – which creates a new log entry which does publicly record the full contents of the notification. This would allow reviewing reports of abuse.

In T58362#9785804, @kostajh wrote:

In T58362#9785578, @Nardog wrote:

Would we enable notifying others in production?

https://gerrit.wikimedia.org/r/928980 allows for sending notification to other users.

With no score caching and requiring the client to make significantly more requests to get the same data, I don't see how this migration has been useful for the end-user so far. The ores-legacy service appears to be slower than the earlier ores service despite giving only 20 scores per request. Ores would provide 50x3=150 scores with lesser latency.

In T357197#9833165, @TheDJ wrote:

In T357197#9833164, @Xover wrote:

You can't make that call with a broad brush like "all of MediaWiki" (or rather, you can only do so extremely conservatively), but when we're talking Gadgets we're inherently at a level of granularity where the community not only can, but is actually best situated to make calls like that.

A granularity that however runs inside the same execution pathways of mediawiki, and thus mixes in with all the other code. It is cool you want to do some redecorating, but we are living in the same house. If you poke a hole in the roof, the whole house has a leak, not just your room.

Cannot reproduce. https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Articles_for_creation/WikiProject_templates.json?action=raw&ctype=application/json gives an application/json response. May have been fixed in the intervening years.

Yes, that issue is T365374. Should be unrelated.

Per the worker logs, we are getting a lot of connection resets while accessing the trove db:

Turns out the issue is quite simpler - only running queries can be stopped. A query in queued state has no db process associated with it, so there's nothing to kill. I don't think the celery based architecture allows unqueuing a task. We should make the stop button appear only after the query starts running.

Still occurring intermittently. Error message suggests a failure in accessing the Trove db. @rook did we make any changes to the setup lately?

I worked on this during the hackathon and came up with a hacky PoC. Will upload it on gerrit in a while.

In T50175#9730478, @Awesome_Aasim wrote:

https://patchdemo.wmflabs.org/wikis/878c4bb105/wiki/A says that the page is in A, even though it clearly is not from the category bar. This might be the "unstable parses" that matmarex was alluding to.

The first 2 are the safest, but the last one opens up the most applications and is by far the most useful.

I don't think that's the issue. We persist the db process id in the query_run table, so even a different pod is able to execute KILL <id> on the db to get the query to stop.

@dcaro I have a stuck pod bot-monitor-28525880-5gm4t in my tool account sdzerobot. The job generally takes only a couple of minutes. But today, I saw the pod has been stuck for 11 days for no explicable reason (nothing relevant in the out or err logs). Grafana shows just 600 kb of memory usage so it doesn't seem to due to OOM.

The proposed patch on Gerrit addresses precisely these problem - it introduces feature parity between gadgets and user scripts ("user gadgets"). All ResourceLoader features available to gadgets like loading dependencies, allowing multiple source pages, specifying peers for FOUC-free CSS loading, CommonJS module support, and conditional loading (based on namespaces, content models, skins, etc), would become available to 'user gadgets'.

Thanks everyone for your support!

In T361036#9663098, @Soda wrote:

My hypothesis here is that the options module ext.pageTriage.externalTagsOptions for PageTriage is being considered a user-generated javascript bundle

The expected usage of this feature is with categories specifically created to be used in Gadgets-definition, so you can just not use a name that contains commas (until the Gadgets 2 migration happens).

Upstream, Ace just last month added support for syntax highlighting vue (https://github.com/ajaxorg/ace/pull/5483).

Had a brief look and it looks good to me. Thanks!

This tool was migrated alright.

Removing subtask as the inline SVG can be server-rendered. It doesn't need to render on the client and so doesn't need any more validation than we do today.

Removing subtask as the dynamically generated SVG can be server-rendered. It doesn't need to render on the client and so doesn't need any more validation than we do today.