Possible race condition: Null Pointer assertion error in CallHierarchy handler

[TomKrcmar2]

When calling callHierarchy/incomingCalls on many locations in files rapidly, I often (but not always) get this error.
The conditions are the same:

• No files in the workspace have changed, but the order I opened or queried them for call hierarchies may have changed.
• My input to the methods are always identical for every run, and always contain CallHierarchyItem data required by the spec, which I originally acquired directly from JDTLS textDocument/prepareCallHierarchy

Oct 08, 2024 2:39:26 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint fallbackResponseError
SEVERE: Internal error: org.eclipse.core.runtime.AssertionFailedException: null argument:start
java.util.concurrent.CompletionException: org.eclipse.core.runtime.AssertionFailedException: null argument:start
	at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315)
	at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:483)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)
Caused by: org.eclipse.core.runtime.AssertionFailedException: null argument:start
	at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:92)
	at org.eclipse.jdt.ls.core.internal.handlers.CallHierarchyHandler.getRange(CallHierarchyHandler.java:237)
	at org.eclipse.jdt.ls.core.internal.handlers.CallHierarchyHandler.getIncomingCallItemsAt(CallHierarchyHandler.java:216)
	at org.eclipse.jdt.ls.core.internal.handlers.CallHierarchyHandler.callHierarchyIncomingCalls(CallHierarchyHandler.java:115)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$53(JDTLanguageServer.java:1167)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$61(JDTLanguageServer.java:1226)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646)
	... 6 more

Investigating, it looks like it may come from a loop here that discovers CallLocations, asserting location.start must not be null, but the call to corext that retrieves the list is not populating the start member field in time. Might indicate a race condition setting this field.