All modified files are not getting deployed when pressing Ctrl+S

[Former user]

Illuminated Cloud version: 2.2.0.5

WebStorm Version: 2021.3.2

I modified multiple classes then hit Ctrl+S, only the current class got deployed. I am aware that “Deploy all modified files” and “Deploy on external change” options have been removed from settings, but there has to be an option to deploy all modified files in one go.

[Jason van Beukering]

• I have the same problem; to replicate

  • Modify two apex classes
  • Press “save all”, only the currently focused class is deployed.

• Interestingly, if you select and bulk format files and then “save all” it does deploy the modified files

‌

[Scott Wells]

Hi. There's been a bit of discussion about this topic in #2041, though that's not really a related issue. Let's move it here. Here's the relevant extract:

It (the "Deploy all modified files" option for "Deploy on save") was optional previously and would end up being enabled by users which would then lead to things either being deployed that those users did not want/expect to be deployed or the opposite...things that they did want/expect to be deployed would not be. This is because the underlying IDE decides which files to include in a save operation based on the relationship between editors and the associated on-disk files and whether they're out of sync. It's unintuitive and was leading to many, many questions and issues.

The preferred way to do is this via the Deploy Modified Files action. When you start a a Deploy Modified Metadata action, the Contents drop-down is focused by default intentionally so that you can quickly change the value. Type M for Module or P for Project to evaluate all module/project files for staleness relative to the org and then hit Enter to start the deployment. It should be very keyboard friendly. I understand that it's still three keystrokes instead of one for these types of multi-file deployments, but in my experience those are less common than the standard Ctrl/Cmd+S to save exactly the current file as part of ongoing development.

What I do have on my backlog, though, is adding the ability to have Ctrl/Cmd+S behavior be configurable so that it either saves the current file or runs an immediate Deploy Modified Files on Project or Module scope with no intermediate dialog. I believe that would be a better way to provide what you're wanting because it's more definitive about what the behavior will be. I can't provide a concrete timeframe for that but will consider moving it forward given this recent change to provide similar (but more predictable) behavior to what was removed.

[Aliaksandr Luferau]

“It's unintuitive and was leading to many, many questions and issues.“

Good to have previous functionality - as optional, as experimental and not supported or something like this. If it possible to make it optional - because for me it works pretty well without any issues (only one was with some previous IDEA release).

For now i still have some issues with saving several files using Deploy Modified Files function: some time it tried to deploy all aura components when i changed only few classes, on other project it each time tried to deploy all objects - for now i am not sure why we need all this complexity when previously all works as expected.

[Scott Wells]

I understand. However, I would rather see any issues found with Deploy Modified Metadata reported and fixed properly so that there's exactly one way to run a reliable "bring org up-to-date" vs. having two similar features that each potentially have their own issues. At least right now I don't see a restoration of the previous Deploy all modified files option, at least not in that form. If it's found that there are use cases for Deploy all modified files that aren't handled properly by a Deploy Modified Metadata-based successor (with any reported issues properly addressed, of course), I'm open to restoring the original option (with caveats, of course), but I don't want to do so until I know that to be the case.

I'm certainly happy to hear that you and others here found that option useful, but I've heard from too many folks about issues when that option is enabled where the only solution was to disable it. And because of the unreliable manner of the JetBrains IDE's file save notifications, it wasn't really possible to provide a decisive fix. That's the same issue that originally drove the Override Save All action which has now been replaced by a different type of listener, but one for explicit action invocation and not anything specifically file state-related.

I just updated the release notes for this week's build with some commentary on this topic. As stated previously, my plan is to restore this type of "bring up-to-date" option for deploy-on-save, but using an effectively headless version of the Deploy Modified Metadata logic, and I plan to do it in one of the near-term releases, likely in the next couple of weeks. Next week's builds are already filled, one for the Salesforce Spring '22 updates and the other for a pretty significant code inspection/formatter enhancement I've been implementing, but this should slot in right after that. Once I release that change, if there are issues with how it's tracking out-of-date state, let's get those reported and fixed so that this is 100% reliable and predictable for everyone, both as part of deploy-on-save and as a standalone action with all of the options offered by the deployment dialog.

Note that in the interim if this is interfering with your workflow, you can revert to the previous build temporarily and then move back onto the latest when I release the successor to this feature. Just download the build archive in the provided link and install it using Settings / Preferences > Plugins > Install plugin from disk (under the gear drop-down menu). Again, I only recommend this as a temporary workaround for those who are significantly affected by this change until analogous behavior is restored shortly.

[Jason van Beukering]

Hi Scott, another issue I’ve observed is when changing the api version of an Apex Class and then saving…. the api version is not saved in Salesforce

‌

[Scott Wells]

Jason, which editor sub-tab has focus when you press Ctrl/Cmd+S? To save the meta.xml file, it must be that sub-tab. I just tried this by opening an Apex class, switching to the Metadata sub-tab, changing the API version number to 60.0 (so I'd know immediately if it was actually saving that file via a failure), pressed Ctrl+S, and sure enough, it resulted in "Invalid api version:59.0".

If the Source sub-tab is selected when you type Ctrl/Cmd+S, it will save the Apex (or Visualforce, Aura, LWC, etc.) file instead, which by default is configured to deploy via the Tooling API. Deployments via the Tooling API don't include the meta.xml file as they're tuned specifically for quick deployments of source file-type metadata.

[Jason van Beukering]

Thanks Scott. I’m a bit of a loss now… Let me explain… I recently updated a bunch of classes to API version 54… obviously Ctrl/Cmd+S won’t save all of the changes… so tried “Deploy all Modified Files” option… IC then indicated that no files had changed… so only options I could is use “Force save” or individually save each file. For me… its seems logical that using Ctrl/Cmd+S should “save” i.e. deploy ALL files that are dirty (i.e make the Salesforce Org look like my local files). So in the case of an Apex class, modifying either the meta or cls files should ensure the class is deployed.

[Scott Wells]

Thanks for the explanation. Deploy Modified Files should definitely pick up changes to supporting meta.xml files and deploy the required pairs of files. Let me see if I can reproduce that behavior. If not, I'll ask you for more specific steps to reproduce. Once I can reproduce this, it's something that should absolutely be fixed.

Oh, and regarding this:

For me… its seems logical that using Ctrl/Cmd+S should “save” i.e. deploy ALL files that are dirty (i.e make the Salesforce Org look like my local files).

That has never been the intention with deploy-on-save. Deploy-on-save was meant to provide a reliable way to deploy the selected file(s)--typically the current editor tab--to the org. It was not meant to be a bring-up-to-date action, and in fact, that's traditionally been an anti-requirement. Deploy-on-save is meant to be a way to enable very fast cycle development when making changes to a specific file, and Deploy Modified/All Metadata have filled the bring-up-to-date role.

While it's true that deploy-on-save when working against a source-tracked org such as a scratch org or a source-tracked sandbox do perform a bring-up-to-date action via sfdx force:source:push, IC2 even offers the ability to treat scratch orgs as if they weren't scratch orgs to enable more fine-grained deployment than afforded by force:source:push as a result of many end users not liking the expensive and sometimes unpredictable nature of that more monolithic deployment action.

One of the key issues with the removed Deploy all modified files option of the deploy-on-save action is that "all modified files" didn't mean "all files that are out-of-date relative to the org". It meant all files which have had their contents changed explicitly in the IDE's editor tabs since the last deployment. And that led to all sorts of confusion because things that were expected to deploy when Ctrl/Cmd+S was typed wouldn't in some situations, and in other situations things that weren't expected to deploy (and perhaps weren't intended to yet) would. There was no reconciling of local vs. org timestamps to determine exactly what should be included, just a notion of what had been explicitly modified locally since the last deploy-on-save action...and not even a successful deploy-on-save because IC2 was clearing the list of modified files before trying the deployment.

So as stated previously, what I plan to do is allow Ctrl/Cmd+S to optionally initiate a headless Deploy Modified Metadata action. If issues are found with how that action tracks dirty state, let's report those and I'll fix them so that it's as close to 100% reliable as possible, and that will provide what you've described, "deploy ALL files that are dirty".

I'll see if I can reproduce the behavior you described and let you know what I find.

[Scott Wells]

Yeah, that was easily reproduced. I'll take care of that for the next IC2 build.

UPDATE: Fixed.

[Scott Wells]

Okay, here is a pre-release build which includes the fix for the reported issue deploying out-of-date meta.xml files and a new configuration option under Illuminated Cloud > Configure Application > Validation and Deployment for Deploy on save > Include all out-of-date metadata that, when enabled (disabled by default), finds all local project metadata that is out-of-date relative to the org and includes it in the deploy-on-save operation alongside the explicitly-selected file(s).

As stated previously, this is effectively the same as running Deploy Modified Metadata and compares local filesystem last modified timestamps to org last modified timestamps (timezone-adjusted) to determine what's out-of-date. That should lead to a much more reliable and predictable version of a bring-org-up-to-date-on-save action, albeit with the additional required expense of the Salesforce API calls required to compare local vs. the latest org timestamps.

For what it's worth, I actually restored the original "deploy all modified files" option into the current implementation and found the same flaky behavior. For example, if you make a change to a file that eliminates differences relative to the project's version control system, that change does not result in an event that allows IC2 to track it as a locally-modified file and it's missed in the next deployment. And that's just one of many strange behaviors that caused that option to be unpredictable/unreliable.

If you'd like to try this, download the attached archive (but don't extract it) and install it using Settings / Preferences > Plugins > Install plugin from disk (under the gear drop-down menu). Then enable the new deploy-on-save sub-option described above and, when you save files, all out-of-date files for the original files' modules should be included in the deployment as well.

If you see issues with that behavior, please feel free to describe them here with enough detail such that the issues can be reproduced. I will likely also ask for deployment debug logs from a reproduction of the issues.

[Former user]

Hello Scott, I followed the steps that you described. But I am noticing a behavior that I'm not sure is intended or not.

• Updated IC2.
• Enabled Include all out-of-date metadata.
• Deleted contents of src folder and fetched everything so that local aligns with the server.
• Updated meta.xml for one class.
• Updated source of another class.
• Press Ctrl+S with second file in focus.
• Finding out-of-date files process started.
• After some time, deployment for a lot of files started.
• I stopped the deployment as I was expecting only two files to be deployed.

Please advise.

[Scott Wells]

Hi, Prashant. That's not quite how it works. This in particular:

Deleted contents of src folder and fetched everything so that local aligns with the server.

When you retrieve metadata from the server, it doesn't set the local filesystem last modified timestamps to match those of the server. They're set by the host operating system based on the time that the file was created/updated by the retrieval process itself. In this manner, the timestamps of all project were were set to something more recent than the server making everything look out of date, hence why everything was deployed. I did look at having IC2 set the last modified timestamps of retrieved files to match those on the server at one point, but there would be no way to have to happen 100% consistently with the Retrieve for Merge process where files are retrieved into a separate temp directory and compared to local project files using either the IDE's built-in diff tool or a third-party tool such as Beyond Compare or Araxis Merge. At that point there's no opportunity to know which files from the retrieve operation were actually copied into the local project, or even if they were merged instead of copied.

As a result, it's important to establish a baseline for this comparison. So basically if you use Deploy Modified Metadata (which is essentially what's happening with this new option, aside from the fact that explicitly-selected files are also deployed unconditionally) on the project metadata, it will select all metadata which appears out-of-date for deployment. If that all succeeds and you run that action again, it should be a no-op because everything is up-to-date. If you then modified a few files and run it again, only those files should be included in the deployment. If you instead used deploy-on-save with this option enabled, the explicitly-selected files and the files modified relative to the server since the last successful deployment should be deployed.

Let me know if that doesn't explain the behavior.

[Jason van Beukering]

Hi Scott. To be clear. If I pull an existing org…change a few files and try and save…IC will attempt to deploy everything?

[Former user]

Hello Scott, your explanation does explain the behavior. But it would be a very difficult feature to use. I regularly pull all metadata from the server to keep my local up-to-date. This will always result in all files being considered dirty. Even if I didn’t didn’t retrieve all metadata, I would not be comfortable with all metadata being pushed from local to server by all the developers in my team. Even if one developer makes a mistake or does something wrong it may cause big issues. The last modified will also be updated on the server for all files unnecessarily.

[Scott Wells]

Hey, all. I committed a cardinal sin of messaging this morning and sent out a quick--and incomplete--response before going into a situation where I couldn't reply again for a few hours. What I said earlier isn't quite accurate, and specifically IC2's out-of-date check doesn't ignore its own retrieval/last successful deployment state. It actually does take those into account such that if metadata was last retrieved since it was last modified locally, the server state is considered more recent. Now, having said that, it sounds like what Prashant reported doesn't match that description.

If you want to see exactly how IC2 determines dirty/out-of-date, you can enable debug logging under Help>Diagnostic Tools>Debug Log Settings by adding the following:

#com.illuminatedcloud.intellij.builder.IlluminatedCloudDeployOnSaveAllActionListener
#com.illuminatedcloud.intellij.builder.IlluminatedCloudSaveAllAction
#com.illuminatedcloud.intellij.builder.ForceComBuilder
#com.illuminatedcloud.intellij.builder.ForceComBuilderUtil
#com.illuminatedcloud.intellij.builder.ForceComMetadataApiDeployer
#com.illuminatedcloud.intellij.builder.ForceComSfdxMetadataDeployer
#com.illuminatedcloud.intellij.builder.ForceComSfdxDeployer
#com.illuminatedcloud.intellij.builder.ForceComSfdxMetadataUtil
#com.illuminatedcloud.intellij.builder.ForceComToolingApiDeployer
#com.illuminatedcloud.intellij.builder.ForceComBuildFailureAnnotator
#com.illuminatedcloud.util.VariableLengthPollingInterval

The key one there is ForceComBuilder as that's where the actual dirty/out-of-date comparisons happen, and IC2 logs its evaluations in a very detailed manner.

With debug logging enabled, if you either run Deploy Modified Metadata or deploy-on-save with this new option, you'll see entries like this following in idea.log:

2022-02-19 17:39:04,135 [91088591]   INFO - tellij.builder.ForceComBuilder - The average server timezone offset for 5 samples is 314 ms. 
2022-02-19 17:39:07,144 [91091600]   INFO - onfigCache.FilePropertiesCache - Enumerated metadata for connection demo in 3 s 9 ms. 
2022-02-19 17:39:07,160 [91091616]  DEBUG - tellij.builder.ForceComBuilder - Querying last modification information for Lightning component contents. 
...
2022-02-19 17:39:07,574 [91092030]  DEBUG - tellij.builder.ForceComBuilder - Comparing local to server timestamps for classes/ShoppingListMobileViewController.cls: 
2022-02-19 17:39:07,574 [91092030]  DEBUG - tellij.builder.ForceComBuilder -   lastDeployedOrRetrievedDate = Fri Feb 18 12:27:12 CST 2022 
2022-02-19 17:39:07,574 [91092030]  DEBUG - tellij.builder.ForceComBuilder -   serverLastModifiedDate      = Fri Feb 18 12:27:12 CST 2022 
2022-02-19 17:39:07,574 [91092030]  DEBUG - tellij.builder.ForceComBuilder -   localLastModifiedDate       = Fri Feb 18 13:23:14 CST 2022 (raw) 
2022-02-19 17:39:07,574 [91092030]  DEBUG - tellij.builder.ForceComBuilder -   localLastModifiedDate       = Fri Feb 18 13:23:15 CST 2022 (adjusted) 
2022-02-19 17:39:07,574 [91092030]  DEBUG - tellij.builder.ForceComBuilder - Local file newer than server representation: classes/ShoppingListMobileViewController.cls 
2022-02-19 17:39:07,574 [91092030]  DEBUG - tellij.builder.ForceComBuilder - Meta.xml file 'ShoppingListMobileViewControllerTest.cls-meta.xml' was modified more recently than metadata file 'ShoppingListMobileViewControllerTest.cls'. Using the meta.xml file's last modified timestamp for out-of-date comparison. 
2022-02-19 17:39:07,574 [91092030]  DEBUG - tellij.builder.ForceComBuilder - Comparing local to server timestamps for classes/ShoppingListMobileViewControllerTest.cls: 
2022-02-19 17:39:07,574 [91092030]  DEBUG - tellij.builder.ForceComBuilder -   lastDeployedOrRetrievedDate = Fri Feb 18 12:26:42 CST 2022 
2022-02-19 17:39:07,574 [91092030]  DEBUG - tellij.builder.ForceComBuilder -   serverLastModifiedDate      = Fri Feb 18 12:26:42 CST 2022 
2022-02-19 17:39:07,574 [91092030]  DEBUG - tellij.builder.ForceComBuilder -   localLastModifiedDate       = Fri Feb 18 12:26:00 CST 2022 (raw) 
2022-02-19 17:39:07,574 [91092030]  DEBUG - tellij.builder.ForceComBuilder -   localLastModifiedDate       = Fri Feb 18 12:26:00 CST 2022 (adjusted) 
...

In the example above, you can see a few things:

1. You can see three different timestamps that are used for the out-of-date check: the last successful deployment or retrieval timestamp of the metadata object; the server last modified timestamp; the local filesystem last modified timestamp, adjusted for timezone to match the server if there's a difference. The newer of the first two is compared to the third to determine out-of-date-ness, so retrieving via IC2 shouldn't cause things to appear out of date. I'm wondering, though, if perhaps that value isn't being adjusted for timezone and that's the cause of Prashant's issue where everything was deployed immediately after a retrieval. A log would say for sure.
2. You can see a file that is found to be newer locally than on the org, and that file will be included in the deployment.
3. You can see a situation where a file's companion meta.xml file is newer than the file itself so the meta.xml file is used for the out-of-date check since it's the newer of the two files that comprise that overall metadata object.

So, if you see a situation where the dirty/out-of-date check isn't yielding the expected results, please enable debug logging, reproduce the behavior, and either attached the resulting log excerpt here or email it to [e-mail] and I'll see what's going on, then fix it.

I'm also still mulling on bringing back the removed simpler "deploy all modified files" behavior in spite of its known issues simply because of the potential expense of the out-of-date check in some orgs. In my orgs--which do have a decent amount of metadata but aren't super densely populated--I see an overhead of ~1-2 seconds for that check. But I know in some larger orgs, the APIs required to enumerate the org metadata can run longer even with IC2's multithreaded approach to querying those APIs.

I'll chew on that, but if you're seeing strange/unexpected results with which metadata gets deployed using this new feature, please help gather diagnostic info so I can address whatever is going on.

Sorry for the misleading info earlier as I was running out the door!

[Jason van Beukering]

Hi Scott

Thanks for the detailed account. I run large teams 20+ developers working on complex enterprise orgs and we’ve been using IC (with the overridden save operation) with hardly any issues for years now. Sure, if you modified multiple files, attempted to save and then got a deployment issue, IC “forgot” which files were modified. This was a minor annoyance compared to the latest situation where it’s fairly hit and miss. Prashant (on this thread) is part of my team and once he’s completed testing, he’ll post logs and findings

[Former user]

Hello Scott, I have emailed the logs to [e-mail]

You would be able to see in the logs, in our org the out-of-date check took more than 75 seconds to complete which will be a huge overhead for every save.

[Scott Wells]

Thanks for the logs. Yes, anything more than a second or two of overhead is too much, so rest assured that there should be no concerns that I'm going to impose that on your overall process. I also see the following in your logs which is a bit confusing (with component names anonymized):

2022-02-20 09:16:40,533 [ 146390]   INFO - onfigCache.FilePropertiesCache - Enumerated metadata for connection T1DEV in 26 s 830 ms. 
2022-02-20 09:16:41,093 [ 146950]  DEBUG - tellij.builder.ForceComBuilder - Querying last modification information for Lightning component contents. 
2022-02-20 09:16:43,765 [ 149622]  DEBUG - tellij.builder.ForceComBuilder - Comparing local to server timestamps for lwc/anLwcName: 
2022-02-20 09:16:43,772 [ 149629]  DEBUG - tellij.builder.ForceComBuilder -   lastDeployedOrRetrievedDate = Tue Nov 30 11:28:01 CAT 2021 
2022-02-20 09:16:43,772 [ 149629]  DEBUG - tellij.builder.ForceComBuilder -   serverLastModifiedDate      = Wed Dec 01 08:50:26 CAT 2021 
2022-02-20 09:16:43,772 [ 149629]  DEBUG - tellij.builder.ForceComBuilder -   localLastModifiedDate       = Sun Feb 20 09:07:33 CAT 2022 (raw) 
2022-02-20 09:16:43,772 [ 149629]  DEBUG - tellij.builder.ForceComBuilder -   localLastModifiedDate       = Sun Feb 20 09:07:33 CAT 2022 (adjusted) 
2022-02-20 09:16:43,772 [ 149629]  DEBUG - tellij.builder.ForceComBuilder - Local file newer than server representation: lwc/anLwcName
2022-02-20 09:16:43,772 [ 149629]  DEBUG - tellij.builder.ForceComBuilder - Server file was last modified by a different user (expected 0054J000006CYVWQA4, found 0054J000000uyI4QAI): lwc/awLwcGoals 
2022-02-20 09:16:43,772 [ 149629]  DEBUG - tellij.builder.ForceComBuilder - Server file has been modified more recently than last deployment or retrieval and should be merged: lwc/awLwcGoals 
...
2022-02-20 09:16:43,853 [ 149710]  DEBUG - tellij.builder.ForceComBuilder - Comparing local to server timestamps for tabs/ATabName__c.tab: 
2022-02-20 09:16:43,853 [ 149710]  DEBUG - tellij.builder.ForceComBuilder -   lastDeployedOrRetrievedDate = null 
2022-02-20 09:16:43,853 [ 149710]  DEBUG - tellij.builder.ForceComBuilder -   serverLastModifiedDate      = Mon Oct 11 10:17:54 CAT 2021 
2022-02-20 09:16:43,853 [ 149710]  DEBUG - tellij.builder.ForceComBuilder -   localLastModifiedDate       = Sun Feb 20 09:07:37 CAT 2022 (raw) 
2022-02-20 09:16:43,853 [ 149710]  DEBUG - tellij.builder.ForceComBuilder -   localLastModifiedDate       = Sun Feb 20 09:07:37 CAT 2022 (adjusted) 
2022-02-20 09:16:43,853 [ 149710]  DEBUG - tellij.builder.ForceComBuilder - Local file newer than server representation: tabs/ATabName__c.tab 

First, the fact that it takes ~27 seconds to enumerate server metadata--which is what it has to do in order to get the server's last modified timestamps--makes this method of dirty detection a non-starter for you...at least as a frequent operation.

Next, I see one component with a value for lastDeployedOrRetrievedDate from November 30, 2021 and another with no value. My understanding is that you were wiping the project clean, then retrieving all metadata into the project to "seed" the initial state, correct? If so, IC2 doesn't seem to be updating that state properly. Can you confirm that's what you did here? If so, I'll see if I can reproduce that behavior locally as that would need to be fixed. It's critical that the timestamp of the last successful deployment from or retrieval to the IC2 project be recorded properly for correct out-of-date calculations.

Finally, in just a moment I'm going to attach a new build here that restores the behavior of the original option, now named Include all files modified locally since the last deploy-on-save. Please install that build, enable the option, and let me know if it's not working as desired again. Note that I may move around and rename these two new options before including them in a final build as I think there's a better way to present and explain the pros and cons of each. As a result, when this does go into a final build--hopefully this coming week's--you may have to re-enable the option in its final form.

[Scott Wells]

Here's the new build that restores the original option as Include all files modified locally since the last deploy-on-save. Install using the same steps and let me know if you see any differences in behavior vs. the previous Deploy all modified files option.

[Former user]

Hello Scott,

I followed the following steps:

• Updated IC2.
• Enabled Include all files modified locally since the last deploy-on-save.
• Delete contents of src folder.
• Open Retrieve metadata dialog.
• Click Update now to update cached metadata.
• Click Retrieve.
• Updated source or meta.xml for one class.
• Updated source or meta.xml of another class.
• Press Ctrl+S with second file in focus.
• Deployment starts for only the file in focus.
• After the deployment completes. Press Ctrl+S with second file still in focus. (Just save without changing focus or anything else)
• Deployment starts for both files.

I have also emailed the logs to [e-mail] for your reference.

[Former user]

My understanding is that you were wiping the project clean, then retrieving all metadata into the project to "seed" the initial state, correct? If so, IC2 doesn't seem to be updating that state properly. Can you confirm that's what you did here?

That’s correct. I wiped the project clean and then retrieved all metadata.

[Scott Wells]

The previous build had a small but significant timing-related issue around when the locally-modified files were gathered for inclusion. This build should address that issue. If you're helping to verify the change, please install it and let me know if it doesn't work as before.

[Former user]

If you're helping to verify the change, please install it and let me know if it doesn't work as before.

Hello Scott, this new build does not have the issue. The functionality is working as expected as before.

[Scott Wells]

Okay, glad to hear. I'll also try to reproduce the behavior that you saw with the other option where it wasn't properly using the last retrieval timestamp. Otherwise I will try to include these changes--perhaps in a slightly different form, though--in this Thursday's build. Thank you for helping to verify the reintegration.

[Former user]

Hello Scott, I’m glad to help.

I'll also try to reproduce the behavior that you saw with the other option where it wasn't properly using the last retrieval timestamp.

Just want to let you know something that I noticed which may help you identify the issue. There is a problem that I have experienced intermittently in the past (this is not specific to recent IC2 updates). I am not able to reproduce the behavior but it happens randomly. High level steps are:

• Have Check for conflicts on deployment feature enabled on the connection.
• Delete contents of src folder.
• Open Retrieve metadata dialog.
• Click Update now to update cached metadata.
• Click Retrieve.
• Make changes to an apex class and save.
• Conflicts Detected window will open up with a update timestamp of 2 days ago (example).

Even though I have the up-to-date class as I just retrieved all metadata, it would still show the conflict. This may be due to the incorrect value of lastDeployedOrRetrievedDate.

I have noticed that this issue happens when retrieving the changes in bulk using Retrieve metadata dialog. But it does not happen then retrieving changes using Refresh metadata feature.

Not sure if this information would help?

[Scott Wells]

That's actually very helpful. I made a note on Friday to ask if you were using conflict detection and, if so, whether you were using dedicated logins or shared logins. If the latter, this method of detecting out-of-date status will not work because the exact same information is used to determine whether a conflict has occurred on a file. I actually have a TODO to disable that feature when used with a connection configured for shared login conflict detection.

[Former user]

We use conflict detection using dedicated logins

[Scott Wells]

Okay. Can you please reproduce this behavior on a small scale (ideally a single file) and send over the resulting log? I'd like to see what's going on.

[Former user]

I’m not able to consistently reproduce the issue. It happens intermittently.

[Former user]

I think the best way to reproduce the problem would be to retrieve all metadata using Retrieve metadata dialog and checking the lastDeployedOrRetrievedDate value for all files, I’m sure some files would have an older or blank value. This incorrect value of lastDeployedOrRetrievedDate is causing various issues.

[Jason van Beukering]

Hi Scott

• I actually just got the problem that Prashant mentioned;
• I did the following:
• Opened retrieved metadata dialog
• Refreshed Cached Metadata
• Initiated the pull request
• While this was happening I cleared local files (except for package.xml)
• Once completed, I was doing code reviews and making minor changes to files.. .when I attempted to “save” this I got a conflict warning
• The warning was indicating that “person x” has changed the file a couple of days ago… this was despite me now having the latest version…..

‌

[Scott Wells]

FYI, I will not be including these enhancements in this week's build only because I want to spend more time testing and verifying. What I will do, though, is provide a new pre-release build here based on what will be today's release but with these changes integrated. You will just install that build as described previously and stay on it for one more week until they're included in an official build. More to come over the next few hours after I've gotten this week's IC2 build out.

[Former user]

Thanks for the heads-up Scott

[Scott Wells]

The fix for the issue with updated supporting meta.xml files not triggering an out-of-date status was delivered in 2.2.0.9. However, the restoration of the removed Deploy all modified files option was not included. I will post a version of 2.2.0.9 with the same changes as the pre-release attached here very shortly. If you're on that pre-release build, please wait until that's available to update.

[Scott Wells]

New pre-release build based on 2.2.0.9. Use the same installation instructions. I feel pretty confident this will go into next week's build so that those of you who have installed it can get back onto the official build.

[Former user]

Thanks Scott

[Scott Wells]

Okay, tomorrow's build will restore the original Deploy all modified files sub-option for the Deploy on save option. Exact same option name and behavior. It will not include the Include out-of-date metadata option. I may yet add that as an option for deploy-on-save, but at present I just want to make things whole again for those who came to rely on the removed option. Once 2.2.1.0 is released tomorrow, it will be safe for those of you on the attached pre-release build to take the official update.

[Jason van Beukering]

Thanks Scott

[Scott Wells]

Delivered in 2.2.1.0. Resolving with the restoration of the specific option that drove this discussion. As I said previously, I may still add an option for a true bring-up-to-date-on-save behavior, but that's beyond the scope of this issue.