Static Resource Folder Retrieval/Refresh is Leaving New or Deleted Files Untouched

[Caleb Weaver]

When working with Static Resources as folders in source format I’m seeing behavior I wouldn’t expect. When a new file is added to the static resource on the server, refreshing the static resource does not bring the new file down. Only a retrieval of the static resource creates the file within the folder.

When a file is removed from a static resource on the server, neither a refresh nor retrieval of that static resource gets rid of that file.

The impact here is that neither of these are obvious when running a refresh or retrieve. Then, when that static resource is deployed, those files are either recreated or deleted from the org’s copy of the static resource.

When running sfdx force:source:retrieve on the file, I get the behavior I expect, which is that all new files are created and all removed files are deleted since the static resource is a single piece of metadata.

IntelliJ IDEA 2020.3.2 (Ultimate Edition)
Build #IU-203.7148.57, built on January 25, 2021
Runtime version: 11.0.9.1+11-b1145.77 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 10.15.7
GC: ParNew, ConcurrentMarkSweep
Memory: 2014M
Cores: 4
Non-Bundled Plugins: Statistic, com.thvardhan.gradianto, indent-rainbow.indent-rainbow, com.antkorwin.unicoder, com.dmarcotte.handlebars, com.illuminatedcloud2.intellij, org.jetbrains.kotlin, com.intellij.plugins.html.instantEditing

[Scott Wells]

What you're saying mostly makes sense, Caleb. When IC2 does a retrieve or refresh of a static resource bundle directly into the local source root of a source format project, it first uses the CLI to retrieve the bundle into a temp directory, then it matches the retrieved files against local files, and then it overwrites those existing files and adds new files. I can see how removed files might end up orphaned, though I'd expect new files to be added. A retrieve-for-merge would show the server vs. local state clearly, but this should work as-expected on retrieve or refresh as well. I'll take a look in one of the near-term builds. Thanks for filing!

[Caleb Weaver]

Thanks for looking into it! That makes sense and to be clear: files are added when doing a retrieve.

I’d still expect even a refresh to just give me exactly what’s in the org since I can’t necessarily refresh a file within a static resource and so I’d expect the whole resource to be refreshed but I can see how that would be intended. I’m also not used to using retrieve-for-merge so that miss is probably on me.

[Scott Wells]

Okay, that makes more sense (that added files are properly conveyed). And while it should work as expected/intended for refresh and direct retrieve actions--and I will fix the identified issues--I do recommend that you take a look at retrieve-for-merge as it allows you to very carefully reconcile any differences between the org's version of the metadata and the local version:

https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/wiki/User_Guide/Retrieving_Metadata.md

[Scott Wells]

Fix submitted for inclusion in the next build. Now on refresh/retrieve-without-merge, all bundle-type metadata is updated exactly based on the server copy.

[Scott Wells]

Delivered in 2.1.7.3.

[Caleb Weaver]

Hey Scott, thanks for the fix! After updating to 2.1.7.3, I’m missing the “Refresh Metadata” command from my right-click context menu and using the shortcut Cmd+option+Shift+R isn’t doing it either.

The one hiccup is that I’m on 2.1.7.3 on a new machine, and my old machine that has the command in the context-menu, hasn’t found the update, so I’m not 100% certain if this is specific to the update or my new computer setup.

Sorry if this ends up being a false alarm, but they seemed related and I wanted to reach out and see if you were seeing similar issues anywhere.

[Scott Wells]

Caleb, what type of connection is being used? Is it a scratch org connection by chance?

[Caleb Weaver]

It’s not, just a sandbox, but I am seeing that at the top of the context menu is Push and Pull. So it seems like somewhere along the line it’s being treated like a scratch org.

‌

[Scott Wells]

If you look at the sandbox connection properties, is the sandbox configured for source tracking? In other words, is Use push/pull instead of deploy/retrieve/delete checked? If so, that would do it. If not, I may need to get some logs from you to see why this connection is being treated as a source-tracked sandbox.

[Caleb Weaver]

Use push/pull instead of deploy/retrieve/delete is unchecked for this connection.

[Scott Wells]

Can you email me a screenshot of the connection being used for the project? Obviously feel free to redact usernames, etc., but I want to see that screen. Also please send me the your idea.log if you don't mind so I can see what it's saying about that connection.

[Caleb Weaver]

Hey again! I’m noticing similar issues on this. I never got around to thoroughly testing the fix but when I do a retrieve of the zipped static resource, I’m seeing some files not get removed and others not get added that should have been removed/added.

[Scott Wells]

Caleb, I'd need to see a debug log of the retrieval. With the changes that were added to (attempt to) resolve this issue, it should log details about retrieval population of bundle-type metadata and when orphans are detected/removed. Please reproduce the behavior with debug logging enabled and either attach or email the resulting logs for review.