Inconsistent fetch status results

[gertjandemulder]

The fetch status shows different results for the same query & authenticated user.

In the following example, the authenticated user, Texon, executes a query over its own data sources.
Hence, every data source's fetch status should be successful (as is the case in the correct example below).
However, the generic data viewer sometimes shows inconsistent results (cfr. incorrect example).

Correct

Incorrect

[mvanbrab]

The cause of this issue is Comunica's caching. I can solve this in two ways (in fact I tested both):

1. Allow fetch status to have 3 values: "Query was successful" / "Query failed" / "Query result reused from cache". This solution correctly represents the way Comunica is used in the code, but might confuse the user, because the resulting display depends on execution order of queries sharing some sources.
   

2. Modify the code to disable Comunica caching (myEngine.invalidateHttpCache(source)). This straightforward solution includes some performance loss in the case of queries sharing some sources, but it doesn't confuse the user.

@gertjandemulder @bjdmeest Please help me choose.

[bjdmeest]

can't you just use the same status icon for 'query result reused from cache'? user doesn't care whether it's from cache or remote, no?

[gertjandemulder]

can't you just use the same status icon for 'query result reused from cache'? user doesn't care whether it's from cache or remote, no?

+1

[mvanbrab]

Solved as proposed in feedback above.

[mvanbrab]

I have to reopen this issue for the following reason, not covered in above solution.

• In a query, where Comunica context property "lenient" is set true, the Fetch status is not shown as failed for resources where authentication failed.

This is a screenshot of such situation. In this case, the authenticated user (brand) does not have access to the first source.

Remark that in this screenshot the (currently experimental code behind the "Verified" column, when executed, tries to fetch the source again and sees the unavailability indeed.

[mvanbrab]

I think this. What if the response code is not OK?