Issue with incorrect deployment failures on creation, but correct once created.

[Robert Conner]

Overview

This is an ongoing issue that I've noticed for a long time now. I always thought it was an issue with Salesforce itself, but submitting in case its an Illuminated Cloud issue.

1. Create a new file NOT in the editor (that also does not exist on the sandbox) Note: don't create the file with Right Click > New. You have to create the file and meta.xml outside of IntelliJ with like vim or (usually in my case by checking it out of git because someone else made it in another sandbox)
2. Deploy file for the first time to sandbox using Illuminated Cloud > Force Save
3. Get error back that makes no sense (and spend hours trying to debug)
4. Create a blank version of that file on sandbox.
5. Deploy again with orginal content, it deploys just fine.

I've seen this happen in both .cls file and .object files. And it always has something to do with sobject relationships.

Reproduce with Class

Create a brand new class and meta.xml with vim and put below query in it and deploy it for very first time to a sandbox

class Foobar {
User user = [SELECT Id FROM User WHERE Profile.Name = 'System Administrator' LIMIT 1]; }

You should see : Deployment Failed: INVALID_FIELD_FOR_INSERT_UPDATE - No such relation 'Profile' on entity 'User'.

Delete the line of code with the query, and then deploy it. Then add the query back in and deploy it again.

Reproduce with Object

(I've forgotten how I produced this error with .object files, I'll update this as soon as I remember)

Reproduce with Visualforce

• In Salesforce Setup, create a custom field on an object (Activity in my case)
• Using vim create a new Visualforce page or component (and meta.xml file) and use the above created field in an apex:inputField
• Deploy for fist time to Salesforce using Illuminated Cloud > Force save
• See error that field does not exist
• Delete reference to new field in the visual force page (delete the apex:inputField)
• Force save deploy should work
• Add apex:inputField line back in and Force save again, should work

[Scott Wells]

Thanks for filing the issue, Robert. First question: are you only able to reproduce this issue in a sandbox? I was going to try to reproduce it in a standard dev org, but if you already know that's not going to work, please let me know and I'll see about getting access to a sandbox.

[Robert Conner]

I've been able to reproduce this with several types of sandboxes: Developer, Partial Copy, and Full. I've never tried with a production system because I always deploy to production with change sets anyways.

[Scott Wells]

Gotcha. I'll try to reproduce against a dev org this afternoon. Hopefully it'll just reproduce immediately and I'll be able to debug/fix it very quickly. If not I might ask you to generate some detailed debug logs so I can see what's happening while I try to get my hands on a sandbox org.

[Scott Wells]

Robert, I had to turn around a quick fix for that issue with unit tests and haven't tried to reproduce this yet. I'll take a look this weekend.

[Scott Wells]

Thanks for the details, Robert. I'll definitely look at this very soon. Hopefully it'll be easy to reproduce with the information you've provided.

[Scott Wells]

Adding to 1.7.9.2 for consideration but not necessarily for implementation just yet.

[Scott Wells]

Okay, the issue is exclusively with creation via the Tooling API. I see the exact same problem when creating this class via the Tooling API but it creates just fine via the Metadata API:

public with sharing class Issue500
{
    User user = [SELECT Id FROM User WHERE Profile.Name = 'System Administrator' LIMIT 1];
}

I was just talking to folks at Salesforce about false negatives via the Tooling API last week and they asked for concrete examples. This is a perfect one because it's SO EASY to reproduce.

The workaround from IC is to disable deployment via the Tooling API when you see this type of error long enough to create the new metadata. It's not ideal, but short of putting in something like prompting the user to retry with the Metadata API when there are failures via the Tooling API, there's no real solution.

I'll let you know what I hear from Salesforce. Thanks for providing a solid example of this class of issues!

[Scott Wells]

Just a quick update...this has been reproduced by Salesforce and seems to be a bug on their end. Evidently the nature of the query causes the bug, so when it includes Profile.Name it occurs but when it includes FirstName it doesn't. The problem only occurs on first creation when this state is present, and only when creating through the Tooling API. The workaround is of course the disable the Tooling API until the metadata is created properly. I could add an option to IC's config to force creation through the Metadata API always. I guess it depends on the frequency of occurrence for you as to whether that's even necessary. Thoughts?

[Scott Wells]

Issue tracker grooming.