Incremental reasoner: AIOOBE in ELK OwlOntologyLoader during processIncremental (GUDID-FULL, second authored concept)

[kec]

Summary

Running the incremental reasoner against a GUDID-FULL Rocks KB after a successful full reasoner run crashes with ArrayIndexOutOfBoundsException deep inside ELK's input-loading stage. The full reasoner on the same KB succeeds. The exception surfaces at the user as UnsupportedReasonerProcessIncremental, which is misleading (see secondary observation below).

Environment

• dev.ikm.komet.classification 1.59.0-SNAPSHOT
• dev.ikm.komet.framework 1.59.0-SNAPSHOT
• dev.ikm.tinkar.reasoner.elksnomed 1.127.2-SNAPSHOT
• dev.ikm.elk.snomed 0.39.7
• dev.ikm.elk.snomed.reasoner 0.39.7
• org.semanticweb.elk.reasoner 0.39.7
• org.eclipse.collections.impl 13.0.0
• javafx.graphics 26.0.1
• Dataset: SOLOR-GUDID-FULL-20250915 (RocksKB)

Steps to reproduce

1. Delete the Lucene folder of a fresh SOLOR-GUDID-FULL-20250915 RocksKB. (Reporter's note — unclear whether this step is load-bearing; see "Open questions".)
2. Open the dataset in Komet via Open Rocks KB.
3. Author a new concept. Run full reasoner → succeeds; concept appears in concept navigator.
4. Author a second new concept. Run incremental reasoner → exception.

Observed behavior

java.util.concurrent.ExecutionException: java.util.concurrent.ExecutionException:
  dev.ikm.tinkar.reasoner.service.UnsupportedReasonerProcessIncremental:
  java.lang.RuntimeException:
  java.lang.ArrayIndexOutOfBoundsException: Index 8388608 out of bounds for length 8388608

Root cause from the trace:

at org.eclipse.collections.impl.set.mutable.UnifiedSet$PositionalIterator.next(UnifiedSet.java:1796)
at dev.ikm.elk.snomed.reasoner.OwlOntologyLoader.load(OwlOntologyLoader.java:125)
at org.semanticweb.elk.reasoner.stages.InputLoadingStage.executeStage(...:215)
... ensureLoading → restoreSaturation → restoreConsistencyCheck → restoreTaxonomy → getTaxonomy
at dev.ikm.elk.snomed.SnomedOntologyReasoner.flush(SnomedOntologyReasoner.java:117)
at dev.ikm.tinkar.reasoner.elksnomed.ElkSnomedReasonerService.processIncremental(...:141)
at dev.ikm.komet.reasoner.ui.RunReasonerIncrementalTask.loadData(...:72)

Full stack trace attached below.

Analysis

UnifiedSet.PositionalIterator.next() failing with index == length from a freshly-obtained iterator is the canonical signature of either (a) the underlying set being mutated/rehashed concurrently with iteration (UnifiedSet is not thread-safe and has no fail-fast modCount on this iterator path), or (b) the loader being handed an axiom set whose contents were swapped between iterator construction and first next(). The 8388608 = 2²³ boundary is incidental — that's just where UnifiedSet's open-addressing table happened to land.

The crash sits in dev.ikm.elk.snomed.reasoner.OwlOntologyLoader (line 125) during ELK's InputLoadingStage, on the restore-then-incrementally-load path. Most likely upstream of tinkar-core, in dev.ikm.elk.snomed 0.39.7. Filing here because the user-visible entry point is ElkSnomedReasonerService.processIncremental; happy to move or cross-file.

Open questions for triage

• Does it reproduce on a smaller KB (concept count well under 2²³)? Tests whether table capacity matters at all.
• Does any incremental run after a full classify fail on this KB, or only when a second new concept is authored between full and incremental? Isolates "delta application" from "saturation restore."
• Behavior with ELK forced to single-threaded loading? Distinguishes concurrent-modification defect from deterministic state-mismatch.
• Is the "delete Lucene folder" step load-bearing? Lucene is unrelated to ELK's axiom loader; if this only repros after Lucene is deleted there's a non-obvious coupling worth surfacing.

Secondary observation — misleading wrapper exception

dev.ikm.tinkar.reasoner.service.UnsupportedReasonerProcessIncremental is thrown from ElkSnomedReasonerService.processIncremental:141 to wrap a real defect. The class name reads as "this reasoner does not implement incremental classification" — but it does, it just failed. This will misroute triage. Suggest either rename to something like IncrementalReasonerFailedException, or split into two distinct types: UnsupportedReasonerProcessIncremental (capability missing) vs. IncrementalReasonerFailedException (ran but threw). Happy to file separately if preferred.

Full stack trace

java.util.concurrent.ExecutionException: java.util.concurrent.ExecutionException: dev.ikm.tinkar.reasoner.service.UnsupportedReasonerProcessIncremental: java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: Index 8388608 out of bounds for length 8388608
	at java.base/java.util.concurrent.CompletableFuture.wrapInExecutionException(CompletableFuture.java:345)
	at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:440)
	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2094)
	at dev.ikm.komet.classification@1.59.0-SNAPSHOT/dev.ikm.komet.reasoner.ReasonerResultsNode.lambda$runIncrementalReasoner$0(ReasonerResultsNode.java:254)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
	at java.base/java.lang.Thread.run(Thread.java:1474)
Caused by: java.util.concurrent.ExecutionException: dev.ikm.tinkar.reasoner.service.UnsupportedReasonerProcessIncremental: java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: Index 8388608 out of bounds for length 8388608
	at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:124)
	at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:193)
	at dev.ikm.komet.framework@1.59.0-SNAPSHOT/dev.ikm.komet.framework.progress.ProgressHelper.lambda$wrap$0(ProgressHelper.java:122)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:328)
	... 3 more
Caused by: dev.ikm.tinkar.reasoner.service.UnsupportedReasonerProcessIncremental: java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: Index 8388608 out of bounds for length 8388608
	at dev.ikm.tinkar.reasoner.elksnomed@1.127.2-SNAPSHOT/dev.ikm.tinkar.reasoner.elksnomed.ElkSnomedReasonerService.processIncremental(ElkSnomedReasonerService.java:141)
	at dev.ikm.komet.classification@1.59.0-SNAPSHOT/dev.ikm.komet.reasoner.ui.RunReasonerIncrementalTask.loadData(RunReasonerIncrementalTask.java:72)
	at dev.ikm.komet.classification@1.59.0-SNAPSHOT/dev.ikm.komet.reasoner.ui.RunReasonerTaskBase.compute(RunReasonerTaskBase.java:63)
	at dev.ikm.komet.classification@1.59.0-SNAPSHOT/dev.ikm.komet.reasoner.ui.RunReasonerIncrementalTask.compute(RunReasonerIncrementalTask.java:64)
	at dev.ikm.komet.classification@1.59.0-SNAPSHOT/dev.ikm.komet.reasoner.ui.RunReasonerIncrementalTask.compute(RunReasonerIncrementalTask.java:32)
	at dev.ikm.tinkar.common@1.127.2-SNAPSHOT/dev.ikm.tinkar.common.service.TrackingCallable.call(TrackingCallable.java:86)
	at dev.ikm.komet.framework@1.59.0-SNAPSHOT/dev.ikm.komet.framework.concurrent.TaskWrapper.call(TaskWrapper.java:78)
	at javafx.graphics@26.0.1/javafx.concurrent.Task$TaskCallable.call(Task.java:1407)
	... 4 more
Caused by: java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: Index 8388608 out of bounds for length 8388608
	at dev.ikm.elk.snomed@0.39.7/dev.ikm.elk.snomed.SnomedOntologyReasoner.flush(SnomedOntologyReasoner.java:117)
	at dev.ikm.tinkar.reasoner.elksnomed@1.127.2-SNAPSHOT/dev.ikm.tinkar.reasoner.elksnomed.ElkSnomedReasonerService.processIncremental(ElkSnomedReasonerService.java:138)
	... 11 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 8388608 out of bounds for length 8388608
	at org.eclipse.collections.impl@13.0.0/org.eclipse.collections.impl.set.mutable.UnifiedSet$PositionalIterator.next(UnifiedSet.java:1796)
	at dev.ikm.elk.snomed.reasoner@0.39.7/dev.ikm.elk.snomed.reasoner.OwlOntologyLoader.load(OwlOntologyLoader.java:125)
	at org.semanticweb.elk.reasoner@0.39.7/org.semanticweb.elk.loading.ComposedAxiomLoader.load(ComposedAxiomLoader.java:48)
	at org.semanticweb.elk.reasoner@0.39.7/org.semanticweb.elk.reasoner.stages.InputLoadingStage.executeStage(InputLoadingStage.java:215)
	at org.semanticweb.elk.reasoner@0.39.7/org.semanticweb.elk.reasoner.stages.AbstractReasonerStage.execute(AbstractReasonerStage.java:152)
	at org.semanticweb.elk.reasoner@0.39.7/org.semanticweb.elk.reasoner.stages.InputLoadingStage.execute(InputLoadingStage.java:60)
	at org.semanticweb.elk.reasoner@0.39.7/org.semanticweb.elk.reasoner.stages.LoggingStageExecutor.execute(LoggingStageExecutor.java:52)
	at org.semanticweb.elk.reasoner@0.39.7/org.semanticweb.elk.reasoner.stages.AbstractStageExecutor.complete(AbstractStageExecutor.java:46)
	at org.semanticweb.elk.reasoner@0.39.7/org.semanticweb.elk.reasoner.stages.AbstractReasonerState.complete(AbstractReasonerState.java:240)
	at org.semanticweb.elk.reasoner@0.39.7/org.semanticweb.elk.reasoner.stages.AbstractReasonerState.ensureLoading(AbstractReasonerState.java:385)
	at org.semanticweb.elk.reasoner@0.39.7/org.semanticweb.elk.reasoner.stages.AbstractReasonerState.restoreSaturation(AbstractReasonerState.java:398)
	at org.semanticweb.elk.reasoner@0.39.7/org.semanticweb.elk.reasoner.stages.AbstractReasonerState.restoreConsistencyCheck(AbstractReasonerState.java:484)
	at org.semanticweb.elk.reasoner@0.39.7/org.semanticweb.elk.reasoner.stages.AbstractReasonerState.restoreTaxonomy(AbstractReasonerState.java:519)
	at org.semanticweb.elk.reasoner@0.39.7/org.semanticweb.elk.reasoner.stages.AbstractReasonerState.getTaxonomy(AbstractReasonerState.java:539)
	at dev.ikm.elk.snomed.reasoner@0.39.7/dev.ikm.elk.snomed.reasoner.ElkReasoner.precomputeInferences(ElkReasoner.java:788)
	at dev.ikm.elk.snomed@0.39.7/dev.ikm.elk.snomed.SnomedOntologyReasoner.flush(SnomedOntologyReasoner.java:114)
	... 12 more