IlluminatedCloud retrieves Email Services to /emailservices/ and fails to deploy and/or conflicts with force:soure:deploy command

[Chris]

• IC Version: 2.1.7.8
• IntelliJ Version: #IC-211.7142.45
• OS: Windows 10 20H2
• Component: Deployment/Retrieval

‌

Summary/Repro Steps:

An email service created via the Salesforce interface is retrieved using IC > Retrieve Metadata > (selected email service). It pulls the metadata file down into:

/force-app/main/default/emailservices

Immediately after retrieving, attempt to deploy using IC > Deploy All Metadata > (selected email service)

Result:

‌

No deployment is actually attempted as far as Salesforce is concerned (nothing in Setup > Deployment Status).

‌

Similarly, trying to deploy from the CLI fails:

PS C:\git\student-support> sfdx force:source:deploy -m "EmailService"
ERROR running force:source:deploy:  The specified metadata type is unsupported: [EmailService]

Attempting to deploy the metadata type similarly fails:

PS C:\git\student-support> sfdx force:source:deploy -m "EmailServicesFunction"
=== Deployed Source
No results found

‌

However, renaming the folder to:

/force-app/main/default/emailservicesfunction

… and attempting a re-deploy using IC works, albeit IC shows the file in the wrong location:

‌

Deploy from the CLI also works:

PS C:\git\student-support> sfdx force:source:deploy -m "EmailServicesFunction"
*** Deploying with SOAP ***
Job ID | 0Af5400001ONHscCAH
SOURCE PROGRESS | ████████████████████████████████████████ | 1/1 Components
=== Deployed Source
FULL NAME          TYPE                   PROJECT PATH
─────────────────  ─────────────────────  ───────────────────────────────────────────────────────────────────────────
InboundCreateCase  EmailServicesFunction  force-app\main\default\emailservicesfunction\InboundCreateCase.xml-meta.xml

‌

Similarly, retrieving via CLI seems to work with the updated folder name:

PS C:\git\student-support> sfdx force:source:retrieve -m "EmailServices"
ERROR running force:source:retrieve:  The specified metadata type is unsupported: [EmailServices]
PS C:\git\student-support> sfdx force:source:retrieve -m "EmailServicesFunction"
(success)

‌

Is IlluminatedCloud pulling this file into the wrong place?

[Scott Wells]

Chris, I just tried to reproduce this, albeit unsuccessfully. Here's what I did:

1. I created an Messaging.InboundMessageHandler implementation and deployed it.
2. I created a new email service, MyEmailService using that class.
3. In IC2 I went into the subscription editor and refreshed the server metadata list, then selected EmailServicesFunction > MyEmailService to add it to the subscription.
4. I used Retrieve Metadata and filtered to show subscribed, server-only metadata which included the new email services function from above, then clicked Retrieve for Merge.
5. It retrieved a file named emailservices/MyEmailService.xml-meta.xml.
6. I opened the retrieved file and used Ctrl+S to deploy it back to the server successfully.

I've verified that the API does report the directory for the EmailServicesFunction metadata type to be emailservices and not emailservicesfunction:

I made sure that it would deploy properly from the CLI as well:

$ sfdx force:source:deploy -m EmailServicesFunction
*** Deploying with SOAP ***
Job ID | 0Af2E00000VWyp3SAD
SOURCE PROGRESS | ████████████████████████████████████████ | 1/1 Components
=== Deployed Source
FULL NAME       TYPE                   PROJECT PATH
──────────────  ─────────────────────  ────────────────────────────────────────────────────────────────
MyEmailService  EmailServicesFunction  force-app\main\default\emailservices\MyEmailService.xml-meta.xml

So the behavior you're seeing certainly seems incorrect. I would recommend that you make sure that your Salesforce CLI is 100% up-to-date, and if it is, I would do a full uninstall/reinstall to see if that resolves the issue. The version I have installed is sfdx-cli/7.101.0 win32-x64 node-v16.0.0.

[Chris]

An all-the-way-up-to-date CLI, you do like to live dangerously!

PS C:\git\student-support> sfdx --version
sfdx-cli/7.101.0 win32-x64 node-v16.0.0
PS C:\git\student-support>

Looks like we already have matching CLI versions, so I think we can eliminate that.

‌

Is the deploy from Ctrl+S the same type of deploy as IC > Deploy All Metadata? Push vs. Deploy?

I was able to Ctrl+S, and then following that a Deploy All Metadata worked successfully, but I didnt change anything else. This is weird.

‌

[Scott Wells]

I just updated my previous post to show a successful CLI-based deployment as well just like the one you tried that didn't work.

Yes, Ctrl+S just does an immediate version of the same thing that Deploy All Metadata would do if performed on the same contextual set of files.

Oh, and the reason that it works when moved under emailservicesfunction isn't because that's the correct directory, but because source format allows for so much more flexible a directory structure. If not present locally, that metadata file would still retrieve into emailservices as that's the metadata type-specific directory name. You could put it under a foobar directory, though, and it should still deploy.

Given that you can reproduce this via the CLI--the issue with force:source:deploy saying that there's nothing to deploy, I mean--tells me that it's likely a CLI issue and not an IC2 issue. In a source format project like this IC2 is just using force:source:deploy and force:source:retrieve to move files back and forth.

I'd recommend completely removing the all vestiges of this metadata file and directory locally and going through the reproduction steps again, this time with debug logging enabled for Metadata Deployment and Retrieval as well as Salesforce DX. If the problem does in fact reproduce, that will yield a very detailed log of what happened including the exact CLI invocations and results. You can share that with me--privately via email if you'd prefer--and I can (hopefully) see what's going on. If it's confirmed to be the CLI, I can tell you which commands to run to reproduce it in full isolation and you can log a bug in the CLI's public issue tracker.

[Scott Wells]

Issue tracker grooming. If this is still an issue, please feel free to reopen, ideally with a concrete reproduction scenario.