Intermittent FIELD_INTEGRITY_EXCEPTION - Variable does not exist: Contact: Source error on LWC Tooling API deploy

[Wacław S.]

Hi

Intermittently I’m getting:

Error:(1, 1) FIELD_INTEGRITY_EXCEPTION - Variable does not exist: Contact: Source

when trying to save an LWC that references apex method via Tooling API.

It seems that the issue caused by a Contact.AccountId reference in User object type var in referenced apex class. Apex class itself deploys fine.

I’m saying that it’s intermittent, but in reality it’s more of “works once or twice, then constantly erroring out”. For instance switching API version in component metadata allows to save component once before going back to errors.

CLI: sfdx force:source:deploy works fine each time.

Attaching debug log.

WebStorm 2021.3 + IC2 2.2.1.2

sfdx-cli/7.142.1 win32-x64 node-v16.14.0

[Scott Wells]

Hi. What you're seeing is another manifestation of this issue:

https://github.com/msrivastav13/DX-Code-Companion/issues/15

By default IC2 uses the Tooling API to deploy LWC, and it incorporates several workarounds for the issue linked above so that the much faster Tooling API can be used as often as possible without explicit user intervention. However, it sounds like there's at least one other corner case that is not yet accounted for. The CLI does not use the Tooling API which is why you don't see this issue via the CLI. As a workaround, you can disable LWC deployment via the Tooling API under Illuminated Cloud > Configure Application > Validation and Deployment > Prefer Tooling API for > LWC. However, I'd like to address this specific manifestation so that you can re-enable that feature.

Unfortunately I'm not seeing the specifics in the provided log. Are you able to isolate the specific usage that causes this issue? So far there are two known problems which can lead to this:

1. Importing a field from the User object, either directly or indirectly.
2. Importing an Apex class that uses NavigationMenuItem/NavigationLinkSet/etc.

Once I am able to reproduce and isolate this, I'll add it to the heuristic used to avoid the linked issue when Tooling API-based LWC deployment is enabled.

[Wacław S.]

Thanks @Scott Wells

Attaching a streamlined lwc + controller bundle that causes this issue. The error message is slightly different, since in my real life setup there are more class layers, but as far as I understand the linked github discussion, it will be the same thing.

‌

‌

[Scott Wells]

Thanks. Easily reproduced and fixed, though if another such corner-case arises, I think I'm just going to have IC2 retry on all FIELD_INTEGRITY_EXCEPTION errors during LWC deployment via the Tooling API. Worst case scenario that would result in a failed deployment via the Metadata API immediately after the same via the Tooling API for a class of legitimate issues, but it address this issue overall. I'd prefer to deal with it tactically, though, so this amendment to the fix/workaround will be included in this week's build (likely Thursday morning). In the interim you can just leave LWC deployment via the Tooling API disabled, then re-enable it once you take the next update.

[Wacław S.]

Thanks! Looking forward to testing it out

[Scott Wells]

Delivered in 2.2.1.3.

[Fernando]

Hi Scott,
I know this issue is fixed, but today I’ve encoutered the same error message, and disabling the tooling API for a LWC fixed it.

Error:(1, 1) FIELD_INTEGRITY_EXCEPTION - Variable does not exist: Email: Source

It failes when trying to referece a couple of fields in the User object. (user.Email, user.CommunityNickname and user.ProfileId)
I’m happy to share the logs, but I just don’t know how.

IntelliJ Build #IU-222.4345.14, built on October 5, 2022
IC2: 2.2.3.9
SFDX: 7.171.0

LWC js file

import {LightningElement} from 'lwc';
import registerUser from '@salesforce/apex/abnRegistrationController.registerUser'

const PHONE_NUMBER_REGEX = "[0-9]{8,12}"; // only number characters between 8 and 12 digits

export default class AbnRegistration extends LightningElement {

    _userRecord = {};
    _businessName = null;

    _isSignUpDisabled = true;
    _isFormValid = false;

    handleFormInputOnChange(event){
        this._userRecord[event.target.name] = event.target.value;
        this.checkFormValidity();
    }

    handleSignUpOnClick(event){
        event.preventDefault();
        console.log(this._userRecord);
        this.createUser()
    }

    createUser(){
        const params = {
            userEmail: '[e-mail]',
            firstName: 'fernando',
            lastName: 'lastName',
            password: 'password'
        };
        registerUser(params)
            .then((result) => {
                console.log('createUser: User created successfully ', result)
                })
            .catch((err) => {
                console.error('createUser:  could not create an user', err)
            })

    }

    checkFormValidity(){
        const allValid = [
            ...this.template.querySelectorAll('lightning-input'),
        ].reduce((validSoFar, inputCmp) => {
            return validSoFar && inputCmp.checkValidity();
        }, true);
        if (allValid) {
            console.log('All form entries look valid. Ready to submit!');
            this._isFormValid = true;
        } else {
            console.log('Please update the invalid form entries and try again.');
            this._isFormValid = false;
        }

    }


    get isSignUpDisabled(){
        // disabled when form is not valid OR businessName is null
        return !this._isFormValid || (this._businessName == null)
    }

    get businessName(){
        return this._businessName;
    }

    get phoneNumberPattern(){
        return PHONE_NUMBER_REGEX;
    }


    verifyAbn(event){
        event.preventDefault();
        this.createUser();
        this._businessName = "Company ABC";
        this._userRecord = {... this._userRecord, 'businessName' : this._businessName};
    }

}

‌

‌

Controller

public without sharing class abnRegistrationController {



    @AuraEnabled
    public static List<String> registerUser(String userEmail, String firstName, String lastName, String password){

        // generating unique value for community nickname.
        String communityNickname = ((firstName != null && firstName.length() > 0) ? firstName.substring(0,1) : '' ) + lastName.substring(0,1);
        communityNickname += String.valueOf(Crypto.getRandomInteger()).substring(1,7);
        System.debug('@FB communityNickname: ' + communityNickname);


        String profileId = '00e5h000003S6FnAAK'; // To be filled in by customer.
        // String roleEnum = null; // To be filled in by customer.
        String accountId = '0015h000010wA5MAAU'; // To be filled in by customer.

        String userName = userEmail;

        User u = new User();
        u.Username = userName;
        u.Email = userEmail;
        u.FirstName = firstName;
        u.LastName = lastName;
        u.CommunityNickname = communityNickname;
        u.ProfileId = profileId;


        return new List<String>{userEmail, firstName, lastName, password, communityNickname, userName};
    }


}

‌

Please let me know if there is anything else I can do to help you to find and fix the issue

‌

Cheers,

Fernando

[Scott Wells]

Thanks for the details. This one is unfortunately a constantly moving target. I think it’s finally time to have a full fallback that retries Tooling API-based LWC deployments that result in a FIELD_INTEGRITY_EXCEPTION once with the Metadata API instead of trying to discern specific patterns. That seems to hold for a while and narrow the overall window of opportunity, but it’s not authoritative. I’ll take a look at that for the next build after I wrap up the Winter '23 updates this week.

[Scott Wells]

Thanks again, Fernando. Easily reproduced and found to be another variation of the types of specific false errors reported by the Tooling API when certain standard objects are used, in this case specifically User. I’ve added support for this variation and it will now automatically retry via the Metadata API. As stated previously, if others crop up I may just decide to always retry FIELD_INTEGRITY_EXCEPTION failures from the Tooling API via the Metadata API, but ideally I would avoid that if possible to keep legitimate such errors from having the additional overhead of a second (likely slower) deployment that will ultimately fail with the same error.

[Fernando]

Thank you for looking into this Scott! Hopefully this moving target got nailed down and will cease to exist once and for all!

[Scott Wells]

Fernando, your instance of this issue should be resolved in 2.2.4.2. Please let me know if it isn’t.