IssueTracker

I talked to reporter offline. This is a regression in EE, we should investigate.

Matthew, can you please take a look at the idea.log? I've only seen issues around

class androidx.fragment.lint.OnCreateDialogIncorrectCallbackDetector$UastHandler tried to access protected method 'org.jetbrains.kotlin.psi.KtClassOrObject 

and

SEVERE - #o.j.c.AsyncPromise - Analyze Error. UNRESOLVED_REFERENCE(a = REFERENCE_EXPRESSION)
com.android.tools.idea.run.deployment.liveedit.LiveEditUpdateException: Analyze Error. UNRESOLVED_REFERENCE(a = REFERENCE_EXPRESSION)

but I'm not sure if that's related.

The stack trace that looks most relevant is this one:

java.lang.NullPointerException
	at org.jetbrains.kotlin.idea.refactoring.introduce.extractionEngine.ExtractableAnalysisUtilKt.createTemporaryDeclaration(extractableAnalysisUtil.kt:379)
	at org.jetbrains.kotlin.idea.refactoring.introduce.extractionEngine.ExtractorUtilKt$generateDeclaration$2.invoke(extractorUtil.kt:464)
	at org.jetbrains.kotlin.idea.refactoring.introduce.extractionEngine.ExtractorUtilKt.generateDeclaration(extractorUtil.kt:664)
	at org.jetbrains.kotlin.idea.refactoring.introduce.extractionEngine.ExtractorUtilKt.generateDeclaration$default(extractorUtil.kt:451)
	at org.jetbrains.kotlin.idea.refactoring.introduce.extractionEngine.ExtractableAnalysisUtilKt.validate(extractableAnalysisUtil.kt:850)
	at org.jetbrains.kotlin.idea.refactoring.introduce.extractionEngine.ExtractableAnalysisUtilKt.validate$default(extractableAnalysisUtil.kt:838)
	at org.jetbrains.kotlin.idea.refactoring.introduce.extractionEngine.ExtractionEngineHelper.validate(ExtractionEngine.kt:33)
	at org.jetbrains.kotlin.idea.refactoring.introduce.extractionEngine.ExtractionEngine$run$3$validateAndRefactor$$inlined$nonBlocking$1.call(nonblocking.kt:29)
	at com.intellij.openapi.application.impl.NonBlockingReadActionImpl$Submission.insideReadAction(NonBlockingReadActionImpl.java:536)
	at com.intellij.openapi.application.impl.NonBlockingReadActionImpl$Submission.lambda$attemptComputation$3(NonBlockingReadActionImpl.java:501)
	at com.intellij.openapi.application.impl.ApplicationImpl.tryRunReadAction(ApplicationImpl.java:1154)

...which unfortunately is coming from the Kotlin IDE plugin. I do not see any upstream YouTrack issues for this, and so far I do not understand the root cause.

There are also some earlier exceptions about missing files in the Gradle cache, but I'm not sure yet if they are related:

2022-10-10 16:54:30,069 [ 169764] SEVERE - #o.j.k.t.e.ExpressionTypingVisitor - Exception while analyzing expression at (35,17) in ~/citymapper/sdk-internal/android/time-date-picker-ui/components/src/main/kotlin/com/citymapper/sdk/ui/timedatepicker/components/TimeDateSpinnerState.kt
org.jetbrains.kotlin.utils.KotlinExceptionWithAttachments: Exception while analyzing expression at (35,17) in ~/citymapper/sdk-internal/android/time-date-picker-ui/components/src/main/kotlin/com/citymapper/sdk/ui/timedatepicker/components/TimeDateSpinnerState.kt
	...
Caused by: java.lang.IllegalStateException: Could not read file: ~/.gradle/caches/transforms-3/ca02ef65710739fadaa13e3a21e420d6/transformed/ui-1.2.1/jars/classes.jar!/androidx/compose/ui/platform/AndroidClipboardManager_androidKt.class; size in bytes: 6944; file type: CLASS
	...
Caused by: java.nio.file.NoSuchFileException: ~/.gradle/caches/transforms-3/ca02ef65710739fadaa13e3a21e420d6/transformed/ui-1.2.1/jars/classes.jar
	...

Some more notes: we've been seeing similar exceptions in this code path since at least AS Dolphin. Sometimes it is an NPE like the above, other times it is a PsiInvalidElementAccessException or an assertion error.

This suggests that ExtractableAnalysisUtilKt.createTemporaryDeclaration may be operating on invalid PSI. One potential cause is that: ExtractionEngine does various work inside background NonBlockingReadActions, and does not appear to check PSI element validity when entering / restarting the read actions. So it is plausible that there could be user edits during the refactoring which invalidate the PSI it is operating on. And indeed, the commit which added the non-blocking read actions occurred in IntelliJ Platform 213 [coinciding with the first crash reports].

afterwards I notice that syntax and error highlighting ends up pretty broken too

This part is much more concerning to me. I am unsure how the ExtractionEngine exception could cause this. Perhaps the exception is a symptom of some different cause indeed.

Is there a particular Android project you can share for which this issue is reproducible?

Thanks! I found a corresponding upstream bug report:

KTIJ-22637: Extract function refactoring does not start until I close another project

I will investigate whether the fix can be backported to Electric Eel / Flamingo.

Quite surprisingly, the root cause is partially in the Android plugin rather than the Kotlin plugin.

In the process of extracting a method, Kotlin makes temporary edits in a LightVirtualFile, apparently using it as scratch space. This happens inside a NonBlockingReadAction, which means that the process is restarted if it is interrupted by a write action. Unfortunately, after Change Ic554e7fd4, the document listener in AndroidFileChangeListener triggers a write action, which cancels and restarts the NonBlockingReadAction. Then the process repeats indefinitely. I've attached the relevant stacktraces.

JetBrains recently submitted a fix (workaround?) here, which changes AndroidFileChangeListener to ignore LightVirtualFiles. I've prepared a cherry-pick at http://ag/20416884 and verified that it fixed the issue. However, I'll assign to Sergey to review and comment on whether a better fix is possible. At first glance, it seems unusual for a DocumentListener to trigger write actions in the first place (and this has apparently led to other issues like this one).

We can probably be more selective to avoid triggering a write action for files that are guaranteed to not affect resource repositories. The write action is there to make sure that file changes affecting resource repositories that are currently being loaded are received by these repositories. Resource repository loading happens inside a read action, so a write action is required to achieve mutual exclusion. This synchronization scheme has very deep roots and is pretty hard to change.

This issue will be fixed by Change I95180ce4c in Electric Eel RC 1.