Just a couple of technical thoughts on this, see if @Catrope , @Mattflaschen-WMF and @SBisson can pitch in --

This should be split up mentally (not necessarily task-wise, just conceptually) to two pieces:

1. The front-end should just not send an AJAX request if a conflict exists.
2. The back-end should prevent needless SQL searches if there's a conflict.

There are several problems with both these parts, though.

Regarding #1 (frontend):

• We need to make sure conflict messages are updated; this is already done thorugh the front-end (it calls the AJAX but then switches the regular 'no result' message with a conflict-specific one)... but -
• We need to update the fieldset. If you are in conflict state and you choose a different limit - how do we treat this? There will definitely not be more results coming in because of the conflict, but we will need to update the state of the fieldset in that case, so we will have to ask for the AJAX anyways. On the fliphand, a user should probably know that choosing limit or from-date or tags, etc while the search is in conflict mode will achieve nothing -- so should we block changing/interacting with the fieldset completely while conflicts exist?

The second bullet point may mean that #2 is moot, and we will have to have the front-end asking for the AJAX anyways, but perhaps only bothering to update the fieldset only.

Regarding #2 (backend):

• This is probably the best solution to prevent needless work, but it means implementing the algorithm that checks whether filters are in conflict. It's not a horrific algorithm but it's also not 100% straight forward, and it will duplicate the front-end's methods, and if we ever change it, will have to be continuously updated as well. Not entirely sure if this is viable -- but even if it is, it definitely shouldn't be urgent.
• Another option to this is to have the front end send a hidden "variable" or something to the backend noting that it's in conflict. This can mean we don't duplicate the algorithm and we short-circuit the results anyways, but it also means that if someone uses the same URL query outside the RCFilters system, the process won't short-circuit.

Which leads me to the final point -- the backend should probably have something allowing to short-circuit even just so we can make sure we have the same behavior for people asking for the results outside the JS. I don't think this is at all urgent, though, because the current situation has conflicts too (it just doesn't show them/say them explicitly) and yet it searches for results - so we won't have any regression if we continue as-is.

The front-end, however, has a potential to do a lot more requests than the current non-RCFilters system, so maybe we need to be more aware of this in the JS side.

I think the first thing to do is to let the server recognize and short circuit useless queries to protect itself and the DBs. Having too many fast queries is much better than few very slow (several minutes) ones. There's always going to be the initial load, explicit page refresh, no-js, that the client-side can't intercept.

More generally I think the server should do more (return structured information about why there's no results, the filters in conflict, etc) and the client should do less (always send ajax query and display results and conflict data as received by the server). But given how we do ajax at the moment (fetching the entire page through http), I would postpone and re-evaluate when new features appear challenging.

Change 347418 had a related patch set uploaded (by Sbisson):
[mediawiki/core@master] RC Filters: Detect filters conflicts to by-pass db query

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

Change 347418 merged by jenkins-bot:
[mediawiki/core@master] RC Filters: Detect filters conflicts to by-pass db query

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

Re-checked conflicting states (per T156427: Implement the Conflict display states and messages) - all the functionality is in place; the performance also seems to be improved (needs to be checked in production).

QA Recommendation: Resolve