- edited description
IlluminatedCloud retrieves Email Services to /emailservices/ and fails to deploy and/or conflicts with force:soure:deploy command
- 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?
Comments (6)
-
reporter -
reporter - edited description
-
repo owner Chris, I just tried to reproduce this, albeit unsuccessfully. Here's what I did:
- I created an
Messaging.InboundMessageHandler
implementation and deployed it. - I created a new email service,
MyEmailService
using that class. - In IC2 I went into the subscription editor and refreshed the server metadata list, then selected
EmailServicesFunction > MyEmailService
to add it to the subscription. - 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.
- It retrieved a file named
emailservices/MyEmailService.xml-meta.xml
. - 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 beemailservices
and notemailservicesfunction
: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
. - I created an
-
reporter 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.
-
repo owner 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 intoemailservices
as that's the metadata type-specific directory name. You could put it under afoobar
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 usingforce:source:deploy
andforce: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.
-
repo owner - changed status to resolved
Issue tracker grooming. If this is still an issue, please feel free to reopen, ideally with a concrete reproduction scenario.
- Log in to comment