Adding a screenshot to illustrate the issue in the task description:
e.g. invalid value in mimeType=jzz
https://commons.wikimedia.beta.wmflabs.org/wiki/Special:MediaSearch?type=bitmap&conceptchips=true&q=rose&mimeType=jzz
will result in the filter label not being displayed:

It's possible to "eliminate" all filters labels:

• Is there a way for us to not remove/eliminate the filters with this error state? That makes this experience feel much more broken and like our mistake/bug rather than a user error.
• In general our goal with error states in search is to: Clearly state there are no results and offer a path forward.
• After chatting with @egardner he mentioned we will know specifically that this is broken due to an invalid value and not just a normal no results state. One easy way forward could be to replicate the current no results state with some updated copy to address all errors related to bad values for media type, filters, etc.

• Eric also brought up a good point about potentially generalizing all of our error messages into one like the example above or below since they are all starting to feel only slightly different. I think this could be a solution but would want us to keep an eye on it being too general to offer the right path forward (As we saw with the end of the results messaging).

In cases with invalid parameters, we might want to use language to convey that we didn't even attempt to find results because the original query was bad. Saying "no results were found" still implies we looked for them; something like "invalid search" might be more accurate here.

That makes sense. I don't think I'd usually use that phrase with most users but with anyone adjusting filters in their URL I imagine they will understand what is going on?

I think this is better – but maybe it would be best to just tell the user to "enter a new search above and try again" or something similar – then we don't need to imply what the cause of the problem was beyond the fact that something in their initial query was not valid (as opposed to a server error or something). I think "try again" should be the take away.

Works for me.

I re-checked how Special:RecentChanges handles incorrect url parameters - it seems it falls back to the default without giving any warning to users.
Special:Search informs users that e.g. "A warning has occurred while searching: Search profile of zadvanced is unrecognized, default search profile will be applied." But in many other cases of incorrect url parameters it falls back to default without informing users.

Simple solution

Potentially more complex but better solution

This experience is an edge case that we should try to spend as little time on. Happy to work with whoever picks this ticket up to finalize any other questions.

Just for the reference: there are three types of failed search requests

(1) failure of infrastructure (unavailable server or some other failure) - I didn't quite tested it.
(2) invalid search terms + - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ /
(3) invalid url parameters. The screenshots in the table below were made for the following urls:

• https://commons.wikimedia.org/wiki/Special:MediaSearch?type=123bitmap&q=mouse&license=cc-by&mimeType=tiff&imageSize=500%2C1000&sort=recency
• https://commons.wikimedia.org/w/index.php?search=mouse&title=Special%3ASearch&profile=56343advanced&fulltext=1&superadvancedSearch-current=%7B%7D&ns6=

Special:Search page gives different warning messages depending on the error. Below is the comparison of the current handling of (2) and (3) types errors.

Type	Special:Search	Special:MediaSearch
(2) invalid search terms	The warning is promptly displayed	The request never ends and there is no warning to users
(3) invalid url parameters e.g. ?type=123bitmap for Special:MediaSearch	&profile=56343advanced	?type=123bitmap - the filters are missing

@mwilliams what do you think about showing this as the error message?

This is *slightly* different from your original mock-up because it still includes the proper page title and help link; the message sits in the content area. It might be helpful to keep those elements to provide some extra context for the user. Thoughts?

Change 667972 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Handle erroneous search filter params in URL

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

@egardner That seems reasonable to me, thanks!

Change 668758 had a related patch set uploaded (by Matthias Mullie; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Handle invalid search strings

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

Change 667972 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Handle erroneous search filter params in URL

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

Change 668758 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Handle invalid search strings

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

Checked in betalabs - the URL parameters have been changed
mimeType -> filemime
imageSize -> fileres
license -> haslicense

Checked for invalid parameters:
filemime - https://commons.wikimedia.beta.wmflabs.org/wiki/Special:MediaSearch?type=image&q=rose&haslicense=other&filemime=tiff123&fileres=%3C500&sort=recency
fileres - https://commons.wikimedia.beta.wmflabs.org/wiki/Special:MediaSearch?type=image&q=rose&haslicense=other&filemime=tiff&fileres=%3C%3F00&sort=recency
haslicense - https://commons.wikimedia.beta.wmflabs.org/wiki/Special:MediaSearch?type=image&q=rose&haslicense=o123ther&filemime=tiff&fileres=%3C500&sort=recency
sort - https://commons.wikimedia.beta.wmflabs.org/wiki/Special:MediaSearch?type=image&q=rose&haslicense=o123ther&filemime=tiff&fileres=%3C500&sort=456

betalabs	screenshot from the comment above

I varied the errors in the URL parameters but the resulting SpecialMediaSearch page always displays the search field and the filters. Since it differs from the screenshot in https://phabricator.wikimedia.org/T271387#6877266, a question to @egardner - given recent hiccups with betalabs, could it be specific to betalabs? Or testing is missing something?
I looked at https://phabricator.wikimedia.org/T273839#6887430 - so the screenshot without filters is only for no-JS case?

@Etonkovidova now that the train has gone out normally again, I think this can be re-tested on production commons (keeping the updated acceptance criteria for error handling from https://phabricator.wikimedia.org/T273839#6959224 in mind). Things seem to be working properly at first glance.

One thing worth mentioning is that unsupported parameters (as opposed to wrong values for supported parameters) are simply ignored, since there may be other parameters being used by mediawiki that we don't know about and don't want to mess with (debug=true for example). So entering filemime=foo should produce an error message, but if the users were to add the old mimeType parameter instead it would just be ignored regardless of its value. I'm not sure that we've formally specified this behavior but it is intentional here.