[api] StoredQueryImpl.createQuery failure

Question

In our Mylyn TFS connector, on creating a Mylyn query, we retrieve a list of stored queries for a project, and then call "createQuery" on each to detemine whether it's a linked query or not.

Now we have a customer that runs into a problem that this StoredQueryImpl.createQuery call fails. While we can protect against that and recover, we are wondering what the underlying issue is. Either we use the API wrong, there is a query which somehow seems to be invalid, or there is a bug in the API that causes query creation to fail under certain conditions.

We don't have much information, but hopefully this stacktrace helps:

com.microsoft.tfs.core.clients.workitem.query.InvalidQueryTextException: The node specified is not found in the classification hierarchy. The error is caused by «'DevTools\Iteration 1'».
	at com.microsoft.tfs.core.clients.workitem.internal.query.QueryImpl.initialize(QueryImpl.java:540)
	at com.microsoft.tfs.core.clients.workitem.internal.query.QueryImpl.<init>(QueryImpl.java:114)
	at com.microsoft.tfs.core.clients.workitem.internal.query.StoredQueryImpl.createQuery(StoredQueryImpl.java:382)

Answer 1

For this error to occur, "DevTools\Iteration1" would have to be an undefined iteration path in the project.   This isn't an error that's thrown due to invalid syntax, but verification that a specified IterationPath has a corresponding IterationPathID in the project.

Is this a valid iteration path in their case?

Thanks,
Rick

Answer 2

Hi Rick

 

I am not sure if the IterationPathID is valid...not sure if I can find out from the customer either.

What I am curious about is though that we are using the TEE to get a list of stored queries. So if we get one from TEE that later failed on the createQuery call, why is it even available? And is there a way to verify if it's a valid query, or do we just have to call createQuery, and if it fails, not add it to the queries the user can select?

Here is the code we use to get our list of queries (we later call createQuery on):

private void showChildren(Project project, QueryFolder folder, List<StoredQuery> queries) {
		QueryItem[] children = folder.getItems();
		for (QueryItem element : children) {
			if (element.getType().equals(QueryItemType.PROJECT) || element.getType().equals(QueryItemType.QUERY_FOLDER)) {
				showChildren(project, (QueryFolder) element, queries);
			} else if (element.getType().equals(QueryItemType.QUERY_DEFINITION)) {
				queries.add(project.getWorkItemClient().getStoredQuery(((QueryDefinition) element).getID()));
			}
		}
	}

Answer 3

Hi Thomas,

Sorry for the delayed response.    One possible explanation for the invalid query is that the iteration path was valid when the query was created but later became invalid as the iterations paths were changed.   I was able to reproduce this error in a stored query by deleting an iteration path which is referenced by a the query, then trying to run the query.  [NOTE: there might be a bug in the TEE client which allowed this query to become invalid.  When the iteration path was deleted I was prompted to chose a new iteration path for affected queries.. it doesn't appear that the substitute path was applied to the affect queries.. i'm still investigating this issue and will open a bug if appropriate]

Regarding your question about validating queries.. As you've experienced, there is no validation of the stored query returned by the by getStoredQuery.  I'm still checking to see if there is a more convenient way to validate a query definition.  I'll report back when I have more information.

Thanks,
Rick

Answer 4

Thomas,

I think the answer to your original question is..

You are using the API correctly and it is correctly returning all queries, including a query that contains a clause that has become invalid.  See the explanation above for a scenerio that would cause the clause to be come invalid.  In team explorer, this query would still be visible and editable.  Attempting to run the query would generate the error you see above until the query is edited and corrected.

I don't see a way to verify the query before attempting to create it.  So as you mentioned, you can call createQuery and handle the exception to exclude this query from your list.

Hope this helps.

Thanks,
Rick

Answer 5

Thanks Rick for your information on this.

Yes, it helps in that we now know how to be present this to the user. We will most likely just hide those queries for now, or show them as disabled.