More logs (161) if you need (30.06-03.07):

Should I close this bug?

No. This is a serious bug in a basic feature that could appear anywhere in the future.

Other pages in MediaWiki namespace preload normally (see sample code below). But not MediaWiki:Create_News page.
This is a recent bug (it worked correctly a week ago) with MediaWiki software.

Thanks. Today this bug does not exist. Even when reconnect through disable/enable network controller. You fixed it. :) I will test for a few more days.

Any updates? It's a very important (breaking) bug.

JavaScript (Browser): https://swviewer.toolforge.org/test.html (see console):

I tried to hardcode EventSource(url, last_id = None), but without effect.
I use streams since 2017, but this bug appeared only 6 days ago (afternoon / in the evening of October 6). Almost all my bot are broken.

This issue there is even in wikimedia’s oauthclient-php.
When user trying to get token. But not in each request, time to time.

Yes, I confirm this summarise.

Several combined streams are bad for mobile (higher traffic, mobile device load) and sometimes maybe dysynch. For works with them need to create "proxy" where info about edits will be "combine" before sends to user's device. But if not impossible make one stream, ok.

@Ottomata Hello, how do you think, can this be done?
At least patrolled and old rev length (without tags), just copy-paste source code from recentchanges stream. It shouldn't be difficult, but it will greatly easer development of tools / speed up tools performance.

In T270755#6711924, @Aklapper wrote:

@Iluvatar: Thanks for the correction! Has this been discussed with WMF-Legal already (see that project for how to contact them)?

Thank you. We will think about contact with Legal. If approval will be received, we're-open this task or re-create new. Thanks to everyone.

Please do not close this task.

1. Wikimedia projects use Mediawiki:Wikimedia-privacypage, not Mediawiki:privacypage.
2. Messages are taken not from TW, but from Mediawiki config. See please:

In T265217#6579234, @Jdlrobson wrote:

Can you expand on the issue you are seeing here @Iluvatar ? I can't see a sidebar in the PDF output of those links and that makes sense to me as both English and Russian are still using uses the default (old) Vector skin for anonymous users. Implementation-wize, DownloadAsPdf creates a session with an anonymous user and runs CTRL+P. Could you share some of the PDFs you have generated via DownloadAsPdf ?

Several unregistered readers reported via social networks that export as PDF not working: files are broken (files cannot be opened). It doesn't work for me too (even via pdf repair tools), see links above and files.

Problem with not only new vector. For example, enwiki, ruwiki.
But in some articles, everything is fine: enwiki.

Strings / doc:
https://github.com/SWViewer/tool-swviewer/tree/master/i18n

My tools: iluvatarbot and swviewer.

1. What exactly should I do? Just replace oAuth callback to swviewer.toolforge.org/...?
2. Is it just about oAuth? If I ignore this notification, will my tools continue working? Will only oAuth be broken or tools is too?

In T241940#5776487, @Masumrezarock100 wrote:

If I understand correctly, you want to retrieve a list of users who is in at least one global group by using API query. But there is no option to continue querying for more results?

Bug was not in specific symbols. Periodically (not always!) EventStream did a defect in random characters of different writing (not only in Cyrillic). One time an error is in "м", and another time "м" is normal, but error is in "y" or "ф".

Ok, but templates in both examples were placed on the same day
Example 1: May 16, 2018;
Example 2: today.

The problem does not always exist. I can not determine the pattern.

The problem is in any article in Russian.
Screenshot of the article Братья Львиное сердце

Problem solved. The user received today a new answer to one of many his letters to Support: "we reloaded GPRS settings". Connection is restored. 1 month later...
Thanks to all.

In T214459#4903299, @ayounsi wrote:

Please try:

• http with the same endpoint: curl -v http://en.wikipedia.org/wiki/Main_Page
• https on a different site: curl -v https://text-lb.ulsfo.wikimedia.org --insecure
• http on a different site: curl -v http://text-lb.ulsfo.wikimedia.org
• https on the same site but different endpoint: curl -v https://upload-lb.esams.wikimedia.org --insecure
• http on the same site but different endpoint: curl -v http://upload-lb.esams.wikimedia.org

See [wikitech] for the full list"

Do you mean "Additional troubleshooting" sectional and curl to http? Is this a completely full list or maybe you need something else? The problem is massive, but this is the first user who agreed to run cURL. We should not lose him :)

In T209794#4807919, @Aklapper wrote:

Is https://phabricator.wikimedia.org/T211477 the same issue? The time frame seems to be the same, and it states that Wikimedia is now blacklisted by mail.ru.

Bugtesr (t) it's my account for test that bug (no rate limit).

Are you saying that we should urgently prioritize this due to someone abusing this?

Yes. The abuse is doing right now, and we have no way to stop it.

Such spammers can not be stopped. Of course account block useless. Right now, the spammer blocked 3 days ago sends spam (otrs 2018112110002672).

When you try to attach mail to an account, server sent to that email asking confirm the action:

Someone, probably you, from IP address xxx.xxx, has changed the email address of the account "%SPAM%" to this address on Wikipedia.
To confirm that this account really does belong to you...

The problem is not resolved :)
Maybe the problem is related to cyrillic symbols or encoding? Although tags not cyrillic...

In T195562#4277072, @Petrb wrote:

Do you actually have these comments in warning templates on Russian wiki? I doubt that.

Yes, of course our templates contain these comments. And yes, it's just a tag for parse.
See 1 or 2.