I've extracted 10k queries from the webrequest logs (notebook1004:/home/dcausse/sparqlqueries.lst)

@Ottomata I updated the task description to indicate the steps needed to make this happen, I probably missed something so could you take a quick look and let us know I missed something important here (e.g. do we need to do something on the refinery/hadoop side to create the hive table and/or add a purge mechanism for the 90days retention).

@Ottomata absolutely this is for analysis purposes

this is a bit puzzling as the response from the backend is sometimes "correct" as it contains a tofu char but sometimes contain the broken surrogate pair which in return will cause mediawiki to fail and certainly causing: T231023

Thanks for the report, there is indeed a problem in the software that is causing this anomaly.

Moving to waiting because as discussed with @Gehel, we don't want to change all tests just for the sake of having unit tests (unless there are other reasons to) but instead migrate the tests as we change the code.

Thanks @mobrovac, we re-enabled the sanitizer and the topics were stable. closing.

Some comments/questions:

Just in case it helps the discussion: here is a list of all the PHP interfaces declared in core and how they are implemented in extensions. In the end there are very few and even fewer are the ones that could not be transformed to an abstract base class. I did not analyze inter-extension dependencies.

Samples are available here: notebook1004:/home/dcausse/phrase_suggester_vs_glent_m1.csv

The API usage of wbsearchentities is higher than usual (https://graphite.wikimedia.org/S/h). This causes the poolcounter to start rejecting queries.
I suppose we could also handle the error path a bit better :
Reading the code I see:

		// FIXME: this is a hack, we need to return Status upstream instead
		foreach ( $result->getErrors() as $error ) {
			wfLogWarning( json_encode( $error ) );
		}