Deploy Modified Metadata wrong timestamp date

[Artur Mialikau]

Hi Scott,

I have problem with timestamp for my apex class on org. So, it is my developer sandbox, and I am the only one who is working with this file. I can see my changes on retrieval, but when I try to deploy my changes to org, I only see 'All files are up-to-date.' message, and here is a log of timestamp comparison:

2019-10-08 16:18:20,339 [98871420]  DEBUG - tellij.builder.ForceComBuilder - Comparing local to server timestamps for classes/CCCLogger.cls: 
2019-10-08 16:18:20,340 [98871421]  DEBUG - tellij.builder.ForceComBuilder -   lastDeployedOrRetrievedDate = Tue Oct 08 16:16:57 MSK 2019 
2019-10-08 16:18:20,340 [98871421]  DEBUG - tellij.builder.ForceComBuilder -   serverLastModifiedDate      = Tue Oct 08 16:16:57 MSK 2019 
2019-10-08 16:18:20,340 [98871421]  DEBUG - tellij.builder.ForceComBuilder -   localLastModifiedDate       = Tue Oct 08 16:05:59 MSK 2019 (raw) 
2019-10-08 16:18:20,340 [98871421]  DEBUG - tellij.builder.ForceComBuilder -   localLastModifiedDate       = Tue Oct 08 16:05:58 MSK 2019 (adjusted) 

The actual file last modified date you can see on the screenshot below (Oct 04):

This happened a couple of times earlier, even on older versions. In this case usually I deploy with Force Save, so it is not a blocker for me right now.

[Scott Wells]

Hi, Artur. IC will use the server date for comparison if it's newer than IC's own last known deployment/retrieval date for that same metadata object. That's what it looks like it happening here. In this case the following dates are being used (rounding to minutes):

• Server last modified date = 2019/10/04 17:15
• Last successful deployment/retrieval date = 2019/10/08 16:17
• Local last modified date = 2019/10/08 16:06

So IC is saying that it has either successfully deployed or retrieved the class more recently than it was last modified on the server, so it will use the last successful deployment/retrieval timestamp for comparison, and that timestamp is more recent than the last modification to the local copy of the file, so the server version must be newer.

I'm going to need to think about that logic, though, because it certainly doesn't seem to be reaching the correct conclusion in this example. There's a reason I implemented it that way, but right now I'm thinking that IC should only use the last successful deployment/retrieval date if no server timestamp is available.

I'll keep this open to track progress on whatever I do. Thanks for reporting!

[Artur Mialikau]

Thanks for reply. I am not sure what kind of Deployment/Retrieval actions are changing last successful deployment/retrieval date, because the only thing I remember what I did was 'Compare With Server', just to take a look what changes I am going to deploy.

For my mind it would make more sense to have some kind of menu or warning to be able to overwrite server changes with local changes in such case. I had a situation when I deployed some set of metadata, and some parts of it was also skipped like in my current case, but some of them deployed correctly and I missed that point because I had a message of successful deployment.

[Scott Wells]

Ah, that provides even more context. Technically Compare With Server uses the same underpinnings as Retrieve Metadata, but it should not be updating the timestamps. That explains what's going on. I'll fix that for sure.

[Scott Wells]

I just dropped a fix for this that will be included in the next build.

[Artur Mialikau]

Thank you, would it be fix for Compare With Server, or some changes in timestamp comparison?

‌

[Scott Wells]

IC will no longer update its timestamps during Compare With Server actions, only during explicit retrievals (and of course deployments).

[Scott Wells]

Delivered in 2.0.9.0.