The following stack trace was produced when preparing 1.2.3 for a release while running the NanoSparqlServer test suite. This trace appears for several REST API methods that attempt to scan the GlobalRowStore in order to report the existing KBs. The root cause appears to be that the GRS was split due to the number of tests that were run and the consequent mutations on the GRS index. Once the GRS was split, the AtomicRowFilter hits the UnsupportedOperationException. This is apparently a long-standing problem, but we normally use the sparse index only for locatable resource metadata, and it is unusual to have so many distinct locatable resources. The large number of unit tests is driving the creation (and destruction) of those mutable resources with the result that an overflow on the DataService journal for the GRS eventually does an IndexSegment BUILD rather than just copying across the tuples in the index to the new live Journal. Once that BUILD is put into play, we wind up with a view of the GRS shard that is comprised of multiple resources (the live journal and an index segment). At that point, a GRS scan will hit this exception.
Based on this analysis, we can write a unit test that would recreate this problem.
The problem with the UnsupportedOperationException in getSourceIndex() is a blocker.
This attribute is probably not used, and we might be able to substitute a ZERO (0) for this specific method, but it needs to be tracked down.