Trigger name not updated in package.xml during refactoring (rename)

Hi Scott,

I’m refactoring a small codebase in a version-controlled SFDX project (deploy/retrieve), shortening trigger names via Refactor > Rename.

IC correctly prompted me for additions/deletions on the sandbox connection (OAuth) which worked fine (success).

The new trigger names look like this:

‌

Whereas the old trigger names are preserved in package.xml:

‌

I didn’t do a lot of research on the subject in the issues history, but I remembered that in ~~#2016~~ you said:

“Old/renamed metadata sometimes remains in the .iml file - Can you provide specific steps to put things in this state? That shouldn’t be the case, and if it is happening, it’s a bug.“
“Note that this is different from if you use a package.xml-based subscription where IC2 is 100% responsible for writing to the file and you’ll see subscription updates happen immediately.“

I end up having items in package.xml which don’t exist anymore on the connection, so this strikes me as a bug.

My Metadata Subscription setting is Always Update:

‌

Logs (session log attached)

The subscription wasn’t updated for a rename operation: (an info-level java.lang.IllegalStateException exception is thrown where I’d expect the metadata subscription update log)

2022-11-18 22:39:22,488 [86233756] INFO - #g.c.GitHandler - [Blaze_PhiloWoe] git -c credential.helper= -c core.quotepath=false -c log.showSignature=false rm --ignore-unmatch --cached -r -- force-app/main/default/triggers/ManageShoppingItemsOnIngredient.trigger force-app/main/default/triggers/ManageShoppingItemsOnIngredient.trigger-meta.xml

2022-11-18 22:39:25,424 [86236692] INFO - #c.i.o.p.u.AbstractProgressIndicatorBase - This progress indicator (Deploying Blaze_PhiloWoe to Blaze_Development_SFDX 1286286862: running=true; canceled=false; task=com.illuminatedcloud.intellij.builder.AbstractForceComMetadataDeployer$1@9cafc7) is indeterminate, this may lead to visual inconsistency. Please call setIndeterminate(false) before you start progress. class com.intellij.openapi.progress.impl.BackgroundableProcessIndicator
java.lang.IllegalStateException
at com.intellij.openapi.progress.util.AbstractProgressIndicatorBase.setFraction(AbstractProgressIndicatorBase.java:196)
at com.intellij.openapi.progress.util.AbstractProgressIndicatorExBase.setFraction(AbstractProgressIndicatorExBase.java:124)
at com.intellij.openapi.progress.util.ProgressWindow.setFraction(ProgressWindow.java:315)
at com.illuminatedcloud.intellij.builder.AbstractForceComMetadataDeployer$1.run(SourceFile:433)
at com.intellij.openapi.progress.impl.CoreProgressManager.startTask(CoreProgressManager.java:442)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.startTask(ProgressManagerImpl.java:114)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcessWithProgressAsynchronously$5(CoreProgressManager.java:493)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$3(ProgressRunner.java:252)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:188)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$12(CoreProgressManager.java:608)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:683)
at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:639)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:607)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:175)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$4(ProgressRunner.java:252)
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:702)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:699)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:699)
at java.base/java.lang.Thread.run(Thread.java:833)

2022-11-18 22:39:25,511 [86236779] INFO - #c.i.i.b.ForceComMetadataApiDeployer - Deployment status = SUCCEEDED
2022-11-18 22:39:28,467 [86239735] INFO - #c.i.i.b.ForceComMetadataDeleter - Deployment status = SUCCEEDED

The subscription was updated for a deletion operation (logically, a merge of 2 triggers on the Preparation__c object into 1):

2022-11-18 23:27:36,295 [89127563] INFO - #g.c.GitHandler - [Blaze_PhiloWoe] git -c credential.helper= -c core.quotepath=false -c log.showSignature=false rm --ignore-unmatch --cached -r -- force-app/main/default/triggers/ManageValuesOnPreparation.trigger
2022-11-18 23:27:36,360 [89127628] INFO - #c.i.i.s.m.ModuleContentsSynchronizationListener - The metadata subscription for module 'Blaze_PhiloWoe' was updated:

ApexTrigger
• ManageValuesOnPreparation [REMOVE]

2022-11-18 23:27:51,801 [89143069] INFO - #c.i.i.b.ForceComMetadataDeleter - Deployment status = SUCCEEDED

Other

In this context I’m also reminded of the importance of keeping track of deletions and being able to automatically include them in a destructiveChanges[Log].xml, #1796.

Logs (session log attached)

Other

Comments (3)