Over a year on, still getting fatal ungraceful errors with large import requests, examples in: T395902

Still failing with ungraceful errors - this example was today to zhwikiversity:

Is this still an issue? I can't seem to reproduce a problem with shift-click or cntrl-cick

releasing if anyone else wants this - the RFC is pretty clear

Declining, as case sensitivity in the local-part "MUST BE" case sensitive per the SMTP specification.

RFC5321(Simple Mail Transfer Protocol) states "The local-part of a mailbox MUST BE treated as case sensitive."

RFC5321(Simple Mail Transfer Protocol) states "The local-part of a mailbox MUST BE treated as case sensitive."

OK, when created please link here then just close this as a WONT FIX.

Perhaps this can changed to a feature request - to include an indicator on the dashboard that a specific course must be managed upstream?

Hi, I don't know who it is. from the dashboard side is this just "expected behavior" and instructors should see the Event Center team?

@Dreamy_Jazz possibly related to this: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CentralAuth/+/dd963421a7c7de2dcb56eba878cf17a3ac570dbf ?

Style guide available here: https://journals.ieeeauthorcenter.ieee.org/your-role-in-article-production/ieee-editorial-style-manual

I suspect we don't need to protect this as a security issue anymore?

To the requester: if commonswiki wants this, they could unblock this range on their project (and optionally replace it with multiple smaller ranges)

In T425460#11972321, @Nemoralis wrote:

In T425460#11891456, @Catrope wrote:

This will be somewhat improved next week with this patch, which includes a link to the reauthentication form in the error message. That's still not exactly what we want, and we'll keep working on more improvements, but it should be slightly better and slightly less confusing than the current situation,

Please, at least make the link clickable.

Agree, this is solved. A community discussion and a group request can be used as needed.

Having a confirmation without deactivating the button isn't going to fix the underlying issue - this form gets repeatedly submitted by users who just keep clicking the submit button.

Ideally, after submitting, this button would become deactivated, along with providing some confirmation that the submission occurred:

In T296102#12038029, @matej_suchanek wrote:

A workaround could be to first change the link to garbage and then remove the garbage.

I tired to remove this from that example wikidata entry above, it failed. Is there a different phab case for claim removal interactions with the SBL?

This seems to be blocked on T121098 ; a project (in this case commonswiki) can't whitelist a subset of a globalblock - doing so would be the fix

The RFC said that existing processes should NOT be broken - they should be updated.

In T426206#11954471, @Yann wrote:

Hi, Many new users on Commons do not get a welcome message, after after editing (I added the message manually):
etc., etc.

FYI: Just tried and PASSED against the original user story in production.

This issue is still occurring in production

[b247c032-6181-4a96-851f-5fb39a961c8f] 2026-05-20 12:02:25: Fatal exception of type "Wikimedia\Assert\PreconditionException"

Not limited to webui, api same fail:

Thank you, I've sent a few emails, and some emailauth users have reported back that they are now getting their codes.

Another yahoo user reporting emailauth problems in https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=17933594

Anyone from the SMTP team looked at this yet? Anecdotally some outbound yahoo mail seems to be working now, but not sure if anything we can do about this is actually resolved?

Verify - this isn't preventing message on CREATE, just autocreate?

Confirmed solved in production

Yahoo SMTP sender admin guide: https://senders.yahooinc.com/best-practices/

Similar to T243937 , closing as no longer able to reproduce. If there is still a current issue, please reopen with details.

I'm going to mark this closed as there are no recent issues, I've personally tested multiple email workflows successful to this domain. Reopen if there are more details that can be worked on.

Ticket suggests this is also preventing things like registration, emailauth, password recovery.

Example VRT Ticket: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=17919480

Note: If I get elevated using a different workflow, then the change content model interface does work during my non-expired time.

Reported in WMF-Stewards meeting today.

For example, using just parameters I was never able to reproduce the user story from this ticket on desktop.

Yes, it seems that even using all the parameters I've found (e.g. https://en.wikipedia.org/wiki/Wikipedia:SOAPBOX?useparsoid=1&useskin=minerva&mobileaction=toggle_view_mobile ) doesn't reliably cause the server to return the same response.

Thanks, so only by "tricking" it client-side.

Aside: is there a reliable method to access the 'mobile' layout on desktop anymore?

Such a mechanism needs to be able to prevent "local project overrides" (at least optionally). Global banned accounts, deceased users, compromised accounts, etc. should never be logging in.

Zunny closed their bug ( https://github.com/znuny/Znuny/issues/779 ) - can we get our side scheduled?

Consumer is still approved: https://meta.wikimedia.org/wiki/Special:OAuthListConsumers/view/5709c54e5e241577730e27c13e1a56cf

Seems like this may make https://meta.wikimedia.org/wiki/Global_reminder_bot no longer needed

Zunny claims to have fixed upstream in v6.5.20

See also T230968

It should also explicitly say that you will be publishing a new page/revision if this workflow is being used to author a new page.

OK thanks, that can be a different UI issue.

OK, forget my comment above -- however this has resulted in a NEW problem - using Special:ChangeContentModel to "create" pages needs work - nothing about it's UI suggests using it will CREATE a page.

The user communication on this seems a bit off, "...all autoconfirmed users can now use Special:ChangeContentModel page to create new pages with custom content models..." ; that Special Page isn't used to "create" pages at all.

I reported there, though that is on a different release (not our LTS train) - but it could be shared code

Can someone check the log.. think it is in /opt/znuny/var/log/otrs.log ?

Example query: https://ticket.wikimedia.org/otrs/index.pl?Filter=%27Unlocked%27;QueueID=%273%27;SortBy=Selection%5B0%5D;View=%27Preview%27;OrderBy=Selection%5B1%5D;Action=%27AgentTicketQueue%27;ChallengeToken=fhGdeFnQQny5OSLtkuAePv0kPGciCBk9;

Possibly related to T421671 ?

FATAL ERROR:

This just started happening today, I think there was a software release yesterday

Note we also semi-regularly get (and process) requests to "un-vanish" accounts just because a project wants the account to have the old name for their records (typically related to disruptive users) so the "system user" is also a bit of a problem there.

I'm not sure what changed, but there is certainly a change around this date, the code referenced above may not be the cause, I don't know what the cause is.

I think this break the rarely used manual account un-vanish process, not to mention simply being inaccurate.

Yes, I'd think the errors should be cleaned up, is a sub-ticket needed?

I'm not sure what the cause of the behavior change is, but this is recent, only seems to be presenting in the last month.

I'm going to close this as no longer able to reproduce, please re-open if you can reproduce the issue.

@Nux for your use case (wanting to copy current code) try ?action=raw

Perhaps that log summary should link to a documentation page?