In T345786#9148039, @JJMC89 wrote:

# is permitted in Page object titles since it represents a link to a section. Spaces before it get removed since MediaWiki page titles don't have trailing whitespace.

In T345786#9148030, @JJMC89 wrote:

# is not permitted in titles. See mw:Manual:Page title#Invalid page titles.

In T345209#9129778, @Xqt wrote:

Instantiation the APISite tries to login with stored cookies but it does not use autocreate [1] for logging in. There might be reasons for it; or should there be a config setting to enable it? A possible way to prevent this issue is to login first via login script: pwb login -all -autocreate -async [2] but I am not really sure whether this works for oauth login because this is quite different from client login.

[1] https://doc.wikimedia.org/pywikibot/master/api_ref/pywikibot.site.html#pywikibot.site._apisite.APISite.login
[2] https://doc.wikimedia.org/pywikibot/master/utilities/scripts.html#login-script

Thanks for reporting this. I consider WCQS pretty much broken in this state, since its results are unreliable and not even showing any sort of error message making this clear. You can do things like changing the whitespace to trigger a refresh of the query, but it's not obvious when you've gotten the "real" answer except when it feels right.

I came here looking for this. To expand on the ask, PageViewInfo metrics currently available are pageviews, siteviews, and mostviewed.

I think it’s the commons.wikimedia.org cookie you need to clear.

In T188684#7521655, @rook wrote:

This was removed...However it was removed in October, not August. I've put in a PR to return the timeout to 24 hours. Though I wasn't able to recreate the results in minikube when I set a short timeout, job seemed to be running after the timeout and the ten minute cull loop.
https://github.com/toolforge/paws/pull/108

I am experiencing this issue as well. I can't upload a 6MB JSON file, when I have uploaded much larger files before—I think even hundreds of MB.

That seems to have done it, I'm in! Thanks so much.

I tried again, and get a different error message:

Logging out and in again didn't do it for me, even with clearing cookies just in case.

I am reopening, since nothing seems to be solved for me. I am getting nothing besides the 500 error for my account DPLA_bot.

When I try, I get:

We need to figure out what happened here. Did the editor drop the ball or did we misunderstand the assignment? And if we can get in January's issue, as our last shot.

I just wanted to comment here, because this behavior is really unclear to me. Does it mean that if I am using the ignore_warnings iterable functionality, I lose access to the message of warnings? I would like to make a bot workflow that raises an error on certain warnings, but then makes a certain action based on the content of the warning received by the API. For example, if the warning is a duplicate one, I might do something after the upload attempt, like move the existing file to the preferred title—but I can't see what it was without logging the warning. Is there a different way to get access to it?