Yes.
An analysis context is a set of files that are all analyzed against the same set of package versions, using the same set of analysis options. An analysis session is the object used to request the analysis of some file within a single analysis context. The exception is triggered when a session is asked to analyze a file and the result of that analysis might be inconsistent with the state of the files in the context at the time the session was created. In that sense it's similar to a `ConcurrentModificationError`.
The easiest way to force the exception to be thrown is to modify the content of one of the files in the analysis context. We don't currently do any fine-grained analysis, so any change will work, but changing the public API of the file being modified will guard against future optimizations (assuming that the file being analyzed is, or depends on, the file being modified).
That should generally work. I can only think of two cases where it wouldn't work
- if the session is modified again after `currentSession` returns but before the result could be computed (the computation of most results is async), or
- if the exception was caused by a need to rebuild the analysis contexts, in which case it seems likely that any sessions built by the old contexts would always throw the exception.
Not knowing why accessing the now current session isn't working makes it hard for me to suggest a more specific solution, but the general approach that I would recommend is the one that we follow in the analysis server, which is to drop back to the point at which we're handling a request and restart from the point where we find the analysis context based on the file path. Not doing so might allow for the possibility of using results computed from two different states of the file system, which could cause invalid results.