Closed bric3 closed 1 year ago
Got this exception com.intellij.diagnostic.PluginException: 316 ms to call on EDT ClearLocalMessageHistoryAction#update@ChangesView.CommitToolbar (com.github.lppedd.cc.vcs.ClearLocalMessageHistoryAction). Revise AnAction.getActionUpdateThread property [Plugin: com.github.lppedd.idea-conventional-commit]
.
@bric3 if I recall correctly, since some time actions can be performed on a background thread instead of allocating the UI one. Probably that's what it is suggesting. See https://github.com/JetBrains/intellij-community/commit/3516f1f202f8d7794432fd7a6e144d1adf6e0886
That's likely, I wasn't able to give some thought on this right now, so I wrote down the exception to come back later at some point.
@bric3 this one is going to be tricky to solve, not because it's difficult per-se, but to keep the compatibility with old versions.
The ActionUpdateThread
enum / UpdateInBackground
interface did not exist prior to mid-2022.
An alternative is to execute the service using a pooled thread so that the action itself completes immediately.
I think's ok at some point to bump the bar, the upgrade rate is pretty good on Jetbrains products.
@bric3 yeah probably. But I'd give ApplicationManager.getApplication().executeOnPooledThread
a go before bumping the minimum version. If it doesn't work straight away, it's totally fair to update IJ version.
Thinking about this issue I think this might not be related to 2023.1. The error happened when upon restart of IJ at a moment when the VCS index was broken. And the initialization of the InternalVcsService
is not yet finished it seems (read lock is still not available).
I suggest to open a new issue for that one where the VcsService initialization could happen on a background thread and make ClearLocalMessageHistoryAction#update
presentation false if the services are not ready.
@bric3 ahhh yes, you're right, as it happens in update
. Isn't there a method on the line of getServiceIfCreated
? I recall something similar. If it returns null
, then we can set isVisible
/ isEnabled
to false.
I'll take a look.
@bric3 thanks! Just don't lose too much time. When you think it's ok to merge, ping me and I'll do it.
@lppedd I think it's better to look at this in another issue/PR and merge the current one.
The
The issue with getServiceIfCreated
now delegates to getService
anyway.getServiceIfCreated
, is that it may not create the service at this point. But the same issue could pop in a different place since this service will be needed at some point.
Merged! Thanks again!
You're welcome
Since changes in 231 are now in a dedicated branch. It feels the right time to fix #108.
The changes are small,
TabAction.Handler
of the platform was converted to Kotlin in 231, and their nullity is now checked by the kotlin compiler.However
JBUIScale
was converted in 223, but the propertyUSER_SCALE_FACTOR_PROPERTY
became private, instead of relying on reflection, I noticed thatJBUIScale
property listener is only fired on this single property before kotlin conversion and after. So I removed the check.