Page MenuHomePhabricator

BannerDataException: Banner name must be in format /^[A-Za-z0-9_]+$/
Closed, DuplicatePublicPRODUCTION ERROR

Description

Error

MediaWiki version: 1.35.0-wmf.16

message
Banner name must be in format /^[A-Za-z0-9_]+$/

Impact

Users get cryptic errors when trying to create CentralNotice campaigns.

Notes

This seems similar to T149240: Viewing Special:CentralNoticeBanners subpage can throw fatal BannerExistenceException, where reportedly the error display was fixed (see also T173782: Display a sane error if the CN banner name is invalid, instead of a cryptic «BannerDataException»), so this might be a regression (in that we’re again seeing a 503 error instead of something more useful).

Details

Request ID
XjQfMApAAEQAAGgQojAAAAAF
Request URL
https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/Edit/Community_banner_templatev2
Stack Trace
exception.trace
#0 /srv/mediawiki/php-1.35.0-wmf.16/extensions/CentralNotice/includes/specials/SpecialCentralNoticeBanners.php(922): Banner->cloneBanner(string, User, string)
#1 /srv/mediawiki/php-1.35.0-wmf.16/includes/htmlform/HTMLForm.php(694): SpecialCentralNoticeBanners->processEditBanner(array, CentralNoticeHtmlForm)
#2 /srv/mediawiki/php-1.35.0-wmf.16/includes/htmlform/HTMLForm.php(586): HTMLForm->trySubmit()
#3 /srv/mediawiki/php-1.35.0-wmf.16/extensions/CentralNotice/includes/specials/SpecialCentralNoticeBanners.php(452): HTMLForm->tryAuthorizedSubmit()
#4 /srv/mediawiki/php-1.35.0-wmf.16/extensions/CentralNotice/includes/specials/SpecialCentralNoticeBanners.php(90): SpecialCentralNoticeBanners->showBannerEditor()
#5 /srv/mediawiki/php-1.35.0-wmf.16/includes/specialpage/SpecialPage.php(575): SpecialCentralNoticeBanners->execute(string)
#6 /srv/mediawiki/php-1.35.0-wmf.16/includes/specialpage/SpecialPageFactory.php(611): SpecialPage->run(string)
#7 /srv/mediawiki/php-1.35.0-wmf.16/includes/MediaWiki.php(298): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#8 /srv/mediawiki/php-1.35.0-wmf.16/includes/MediaWiki.php(967): MediaWiki->performRequest()
#9 /srv/mediawiki/php-1.35.0-wmf.16/includes/MediaWiki.php(530): MediaWiki->main()
#10 /srv/mediawiki/php-1.35.0-wmf.16/index.php(46): MediaWiki->run()
#11 /srv/mediawiki/w/index.php(3): require(string)
#12 {main}

Event Timeline

Still reproducible. @DStrine What is this blocked on / or / who is the not-fr-tech this should be passed onto?

hmm I am not sure. I will have to ask the team tomorrow and get back to you.

@Quiddity and @Seddon as fYI

There should be some validation and better messaging about banner names. We should communicate this to CentralNotice admins. Fr-tech won't be able to address this in the near term due to other priorities

Change 611713 had a related patch set uploaded (by Umherirrender; owner: Umherirrender):
[mediawiki/extensions/CentralNotice@master] Validate banner name on SpecialCentralNoticeBanners for delete and clone

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

Just to check, was this communicated to the CN-admins? (I'm not on that mailing list) Sorry I didn't notice this task earlier.
If it wasn't, and if the above patch doesn't solve it, then hopefully @Jseddon can send an email, and perhaps we could also amend the interface strings within the UI itself to provide a clear reminder/warning?
I cannot see the UI (as I'm not a CN-admin), but presumably something within https://meta.wikimedia.org/wiki/Special:CentralNotice?uselang=qqx

As I understand it, there is no need for immediate user communication in regards to this task. This task is about the fact that there are, already, banner names that we don't allow in CentralNotice. Today, when those are encountered, we fail with an application crash, which in turn raises error levels for production mediawiki and can randomly raise alarms or halt deployments.

The outcome for this task is to catch these errors and display a message to the user (user/content error, instead of system error), which in turn menas they will no longer raise the internal alarams or serve confusing system error pages to users.

If there's a need to better document these limitations and/or for names to become more flexible, that's imho orthogonal as those limitations have been in place for years.