JQL Filter fails when query is "project = key"

We're currently using search() method from your com.atlassian.jira.bc.issue.search.SearchService. Because of changes introduced in JIRA 7.1 we're experiencing problems when doing simple queries in the form "project = key".
In such cases, the result is a nice exception thrown as following:

Caused by: java.lang.NullPointerException
at com.atlassian.jira.instrumentation.DefaultInstrumentationListenerManager.getCurrentTraceId(DefaultInstrumentationListenerManager.java:200)
at com.atlassian.jira.issue.search.providers.DualSearchProvider.recordMetrics(DualSearchProvider.java:169)
at com.atlassian.jira.issue.search.providers.DualSearchProvider.performSearch(DualSearchProvider.java:138)
at com.atlassian.jira.issue.search.providers.DualSearchProvider.search(DualSearchProvider.java:79)
at com.atlassian.jira.bc.issue.search.DefaultSearchService.search(DefaultSearchService.java:111)
at com.keplerrominfo.sil.lang.AbstractRoutine.execute(AbstractRoutine.java:78)
at com.keplerrominfo.sil.lang.grammar.ASTCallNode.interpret(ASTCallNode.java:72)
... 18 more

Surprisingly,

"summary is not EMPTY and project = key"

works, however

"project = key and summary is not EMPTY" 

does not work, the result is the same exception (shown above).
Although the problem is not in the service itself, the class to blame is DefaultInstrumentationListenerManager, which introduced a new ThreadLocal variable requestData with the purpose of recording statistics.

We, at Kepler-Rominfo, consider this a bug because queries should be symmetric and should work even if the execution of the query is on another thread than the one that initiated the call.

Plus, we do not consider that every service call coresponds to a real web request (our case, most of the time). Using DefaultInstrumentationListenerManager.startContext() on our own thread doesn't seem appropriate.

The same problem manifests when using search() method from SearchProvider.