Change #1099149 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/core@master] ApiBlock: Start adding multiblocks support to the action=block API

https://gerrit.wikimedia.org/r/1099149

We talked a bit the other day about how to interpret having both a user and blockid param, and I think we decided to throw an error if both are provided. The description currently says "No need for a username/ip", but I don't think we want to support changing the target of a block, so I'll change that.

Change #1089710 merged by jenkins-bot:

[mediawiki/extensions/MediaSearch@master] SpecialMediaSearch: Add error handling for search API errors

https://gerrit.wikimedia.org/r/1089710

If my hypothesis about what caused this is right then the fix for T380126 in WMF-5 will have caused this error to stop happening. Otherwise more details (i.e what the parameters of the API request are) will be needed to debug.

Closing per last comment. If there is still work to be done, this can be reopened.

Haven't seen this error anymore, neither with Pywikibot 9.3.1 not with the current master 9.6.0. Maybe it is solved upstream somehow :

I don't immediately see how this is related to the Translate extension but feel free to correct me

@roman-stolar: Removing task assignee as this open task has been assigned for more than two years - See the email sent to task assignee on October 11th.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

@Ifeatu_Nnaobi_WMDE , @WMDECyn , this looks like one for your team. happy to chat about the details if needed

Why Special:Watchlist, why not Special:EditWatchlist or Special:EditWatchlist/raw? All three can be equally appropriate, so none of them is really appropriate.

Pass Special:UserLogin or Special:Watchlist respectively?

In T379808#10329392, @Pppery wrote:

And the ApiUsageException tree should pass a title to truly render this class of errors moot once and for all.

Actually I could totally imaging this happening:

Note that the template call doesn't need to be in the message - it's far more likely to be in the parameters to the message. There are a bunch of messages that include parameters with user controlled text that could trigger in this context, but the only ones that are at all plausible are AbuseFilter and Translate's syntax checker for invalid translate syntax.

In order for it to reach the place in the stack trace it does, it must produce AS_HOOK_ERROR or AS_HOOK_ERROR_EXPECTED. The latter case can only ever trigger with the hookaborted message, which is pure, so that's a non-starter.

Ideally we would know what that message is that is doing something weird. Unfortunately the stack trace doesn't tell us.

In T379808#10318870, @Nikerabbit wrote:

This was supposed to be fixed by rETRA68d2e8d5ffe7: Avoid calling Parser::getPage() when no title is set but something is parsing an interface message without the interface message flag set.

In T16712#193524, @Umherirrender wrote:

lenamespace was added with gerrit 135283

I really don't know what else I could add. The change currently suggested in https://gerrit.wikimedia.org/r/1089273 is wrong or at least misleading. Start enumeration from this revision's ID sounds like the entries would be filtered and odered based on their revision ids. But this is not what happens. The entries are filtered and ordered starting with the timestamp of the revision identified by the revision id in start.

Yes, this is how it converts them internally. But purpose is to provide (in API call) ID to startid and if you want to provide timestamp instead, start.

I'm really sorry, but I don't understand what you mean. There is an existing field for providing a timestamp called "start". But that's not what's discussed here. I found it helpful to read the code to understand better how the different "start"/"startid" and "end"/"endid" fields interact.