- edited description
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 you said:#2016
- “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.
Comments (3)
-
reporter -
repo owner Fix committed for the next build.
-
repo owner - changed status to resolved
Delivered in 2.2.5.0.
- Log in to comment