Need distinct per-client metadata container names to avoid collisions

[Nunzio Capasso]

Hello guys , i am currently esperiencing this issue: "Deployment Complete: Deployed 0/0 components to DEV01 in 3m 33s 477ms with status QUEUED. " Does anyone know what is causing this error? I am currently using IntellijIdea with Illuminated Cloud 1.8 but other colleagues reported me the same issue with the 2.0.

I've already posted the issue on the salesforce forum but i didn't got an answer yet, so could it be an IC problem? Does anyone experinceded this issue before?

Thanks, Nunzio.

Link SF forum discussion: https://developer.salesforce.com/forums#!/feedtype=SINGLE_QUESTION_DETAIL&dc=Developer_Forums&criteria=OPENQUESTIONS&id=9060G0000005WWjQAM

[Scott Wells]

Would you mind enabling debug logging for deployment as documented here:

http://www.illuminatedcloud.com/support/debuglogging

and sending me the log of a deployment that fails in this manner? That should hopefully show me exactly what's happening.

[Nunzio Capasso]

Thanks for the quick answer Scott. Here it is the log (from one of my colleagues).

[Scott Wells]

Thanks for the log. I can see what's happening, but I don't really understand it:

2018-03-23 11:05:53,006 [4108808]  DEBUG - der.ForceComToolingApiDeployer - ContainerAsyncRequest is still processing. Waiting com.illuminatedcloud.util.VariableLengthPollingInterval@dc9e243 milliseconds and trying again. 
2018-03-23 11:05:53,006 [4108808]  DEBUG - .VariableLengthPollingInterval - ForceComToolingApiDeployer.runContainerAsyncRequest: Using polling interval 5000 ms for polling iteration 56. 
2018-03-23 11:05:58,009 [4113811]  DEBUG - der.ForceComToolingApiDeployer - Polling the status of the ContainerAsyncRequest. 
2018-03-23 11:05:58,274 [4114076]  DEBUG - der.ForceComToolingApiDeployer - Expected one ContainerAsyncRequest row but received zero. Ending poll for status. 

Basically the Tooling API MetadataContainer object used for deployment is there and we're polling successfully, and then it's just...gone.

Let me ask this...is this org only being used by you, or are you sharing the org with others by chance? If you're sharing, are multiple people using a connection name of DEVEV01? That might explain it...the metadata container name right now is based on the connection name, in this case IC-DEVEV01. If two people deploy concurrently, I could see one user's existing request being wiped out unintentionally by another person because of both converging on the same name.

If that's in fact what's happening, I just need to make the metadata container name unique per-client to ensure this type of collision doesn't occur. Can you confirm that to be a possibility here (or not)?

Thanks again for the log...

[Nunzio Capasso]

Yes, that's probably the case. I just checked with 4 of my collegues and 3 of them were using the same connection name (DEVOVO1). We are currently working on a very big project with hundreads of people working on the ORG named "DEVOVO1" , so it's very likely that a alot more people are now using the same connection name.

(The collegue with the different and "strange" connection name didn't experience any issue.)

Thank you very much for the quick and helpful answer :)

[Scott Wells]

Okay, that explains it. Thanks for confirming. This is definitely mine to fix! I can make sure that the metadata container names are distinct per-client, especially since it's a best practice to share a connection name so that you can also check in and share project config files. I'll try to turn that around quickly. In the interim you can use distinct connection names or disable deployment via the Tooling API since the Metadata API won't have this issue. Neither is a great workaround, so like I said, I'll try to get a fix out ASAP. Thanks again!

[Scott Wells]

I'll also make sure that the fix goes into both IC1 and IC2.

[Scott Wells]

Just submitted a fix for the next build.

[Nunzio Capasso]

Thanks Scott , we all really appreciate what you are doing for us.

[Scott Wells]

Delivered in 1.8.2.3 and 2.0.1.4.