Project incorrectly stuck in Source Tracking mode

[Jason Clark]

I have a project that has long been in Metadata format (with a src/ directory). I’ve just converted it to source format (with a /force-app directory) using the following steps:

1. create a simple sfdx-project.json
2. create a force-app/main/default tree
3. sfdx force:mdapi:convert -r src
4. Remove the old src directory.
5. In IC > Configure Project, add force-app as a Source folder and remove src.
6. Rebuild the OST

I’m pretty sure these are the same steps I’ve followed on other projects without issue. But in this case, my project is now stuck in source tracking mode - Tools > Illuminated Cloud shows “Push” and “Pull” commands instead of the Deploy/Retrieve commands.

There are a couple of wrinkles - I also had to switch sandboxes at the same time. I’m using an SFDX oauth connection for the sandbox. I can retrieve metadata just fine. I also checked the connection under Tools > Illuminated Cloud > Connections, and confirmed that the “Use push/pull instead of deploy/retrieve/delete” box is NOT checked. I have also confirmed that source tracking is NOT enabled in the client’s prod Dev Hub, so push/pull shouldn’t even be an option. Running sfdx force:source:status returns “ERROR running force:source:status:  This command can only be used on orgs that have source tracking enabled, such as sandboxes and scratch orgs,” although it is very slow (minutes) to respond with the error.

I would normally use Force Save to push individual files in this project, but that option simply doesn’t appear to work when a project is in source tracking mode. As a workaround, I tried sfdx force:source:deploy directly from the command line, and got a “Not available for deploy for this organization” error; it turns out my sandbox user’s profile had not been changed to Sys Admin.

Once that was fixed, I confirmed that I can now force:source:deploy from the command line. Then I ran "Force update SFDX connections" and even restarted WebStorm, but I still can’t Force Save files, and the Illuminated Cloud menu still shows Push and Pull options.

I’m out of ideas. I’m on WebStorm 2022.2.2, and IC 2.2.3.7. I just updated sfdx a day or two ago, here are my versions:

DX Version:
sfdx-cli/7.169.1 darwin-x64 node-v17.2.0

Plugin Versions:
@oclif/plugin-autocomplete 1.3.0 (core)
@oclif/plugin-commands 2.2.0 (core)
@oclif/plugin-help 5.1.12 (core)
@oclif/plugin-not-found 2.3.1 (core)
@oclif/plugin-plugins 2.1.0 (core)
@oclif/plugin-update 3.0.0 (core)
@oclif/plugin-version 1.1.2 (core)
@oclif/plugin-warn-if-update-available 2.0.4 (core)
@oclif/plugin-which 2.1.0 (core)
@salesforce/sfdx-plugin-lwc-test 1.0.1 (core)
alias 2.1.0 (core)
apex 1.2.0 (core)
auth 2.2.5 (core)
community 2.0.1 (core)
config 1.4.19 (core)
custom-metadata 2.0.0 (core)
data 2.1.2 (core)
dependencies-cli 2.0.1
generator 2.0.2 (core)
info 2.1.0 (core)
limits 2.0.1 (core)
org 2.2.3 (core)
packaging 1.9.1 (core)
salesforce-alm 54.8.1 (core)
schema 2.1.3 (core)
sfdx-cli 7.169.1 (core)
signups 1.2.0 (core)
source 2.0.13 (core)
telemetry 2.0.0 (core)
templates 55.1.0 (core)
trust 2.0.4 (core)
user 2.1.2 (core)

‌

[Scott Wells]

So as you’ve mostly surmised, IC2 will treat it as a source-tracked project if it sees the connection as either a scratch org not configured for deploy/retrieve/delete instead of push/pull or a non-scratch OAuth org configured for push/pull instead of deploy/retrieve/delete. The configuration options are IC2-specific, but the scratch org status is derived from the CLI’s force:org:list and force:org:display commands. Can you please run sfdx force:org:list --json and see whether this org shows up as a scratch org or as a non-scratch org?

[Jason Clark]

It is listed in the nonScratchOrgs section. Here is the (obfuscated) entry:

{
                "accessToken": "00D...", 
                "instanceUrl": "https://jxxx--rxxx.my.salesforce.com", 
                "orgId": "00DxxxxxxxxxxxxXXX", 
                "username": "jxxx@jxxx", 
                "loginUrl": "https://jxxx--rxxx.my.salesforce.com/", 
                "clientId": "PlatformCLI", 
                "isDevHub": false, 
                "instanceApiVersion": "56.0", 
                "instanceApiVersionLastRetrieved": "9/27/2022, 3:36:07 PM", 
                "name": "JXXX", 
                "instanceName": "CS201", 
                "namespacePrefix": null, 
                "isSandbox": true, 
                "isScratch": false, 
                "trailExpirationDate": null, 
                "tracksSource": false, 
                "alias": "jxxx_rxxx", 
                "lastUsed": "2022-09-28T15:03:54.154Z", 
                "isDefaultUsername": true, 
                "connectedStatus": "Connected", 
                "defaultMarker": "(U)"
            },

‌

[Scott Wells]

Okay, let’s check the cache that IC2 is using for SFDX connections. On a Mac that’ll be under ~/Library/Application Support/JetBrains/WebStormXXXX.YY/options/illuminatedCloudSfdxCache.xml. First, check the entries for this specific connection and see if it looks correct to you. If it does, please completely restart WebStorm and see if you have the same behavior. I know you listed that in your steps above, but if the persistent cache is correct, a restart will cause IC2 to pick that up and we’ll know for sure that it’s working with the correct information.

If it’s not correct, please try the Force Refresh SFDX Connections action one more time, close the IDE entirely, and check that file again to see if that has corrected it. If it hasn’t, with the IDE still closed, remove that file completely and start the IDE.

Let’s do those and see where we are. Any variation of this is obviously not expected behavior, but let’s see which is happening.

[Jason Clark]

I found the file, but I can’t tell if it looks correct or not; nothing seems to related to source-tracked vs non. I see it in three places:

in orgDisplayResponses:

<entry key="jxxx_rxxx">
    <value>
        <OrgDisplayResponseCacheEntry>
            <option name="orgDisplayResponse">
                <SfdxForceOrgDisplayResponse>
                    <option name="result">
                        <SfdxForceOrgDisplayResult>
                            <option name="accessToken" value="00D..." />
                            <option name="alias" value="jxxx_rxxx" />
                            <option name="clientId" value="PlatformCLI" />
                            <option name="connectedStatus" value="Connected" />
                            <option name="id" value="00Dxxx" />
                            <option name="instanceUrl" value="https://jxxx--rxxx.my.salesforce.com" />
                            <option name="username" value="jxxxk@jxxx" />
                        </SfdxForceOrgDisplayResult>
                    </option>
                    <option name="warnings">
                        <list>
                            <option value="This command will expose sensitive information that allows for subsequent activity using your current authenticated session.&#10;Sharing this information is equivalent to logging someone in under the current credential, resulting in unintended access and escalation of privilege.&#10;For additional information, please review the authorization section of the https://developer.salesforce.com/docs/atlas.en-us.234.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_web_flow.htm" />
                        </list>
                    </option>
                </SfdxForceOrgDisplayResponse>
            </option>
            <option name="orgDisplayResponseLastPopulated" value="1664377435542" />
        </OrgDisplayResponseCacheEntry>
    </value>
</entry>

In orgListResponse:

<SfdxForceOrg>
    <option name="accessToken" value="00D..." />
    <option name="alias" value="jxxx_rxxx" />
    <option name="instanceUrl" value="https://jxxx--rxxx.my.salesforce.com" />
    <option name="lastUsed" value="1664379504661" />
    <option name="loginUrl" value="https://jxxx--rxxx.my.salesforce.com/" />
    <option name="orgId" value="00D..." />
    <option name="username" value="jxxx@jxxx" />
</SfdxForceOrg>

and an entry in sfdxConfigFileChecksums.

That said, I tried ‘Force Refresh Connections’ followed by an immediate restart, and now it’s working. It seems like the only difference in the cache file is the timestamps, but maybe I’m overlooking something. At any rate, thanks for the assist, I seem to be back up and running now.

‌

[Jason Clark]

See last comment - force refresh and restart seems to have done the trick.

[Jason Clark]

@Scott Wells Sorry, I need to reopen this… it turns out that I had accidentally opened another project. When I returned to the correct project, I still have the same problem. So I deleted the cache file and restarted, and I still have the same problem.

[Scott Wells]

Okay. So it sounds like perhaps something was wedged in the in-memory cache incorrectly if a restart after a force refresh resolved the issue. I’ll look into that and see if I can figure out why that might happen. So sorry for the frustration and inconvenience.

[Jason Clark]

See Last comment - issue is not resolved.

[Scott Wells]

No problem. Give me a few to try to figure out what else to check…

[Scott Wells]

Okay, let’s try something simple just to see if it works. Please remove that org authorization and reauthorize using a different alias, then set that as the project connection. Let’s see if it’s something tied to potentially or even invalid information about the existing auth or something more tied to the associated org.

[Jason Clark]

Creating a new SFDX connection/alias and switching IC2 to that connection seems to have fixed it - although i still see push/pull in the IC menu (and I don’t in other non-source tracked sfdx projects), Force Save now works. On a whim I restarted, and the syntax highlighter went nuts, showing everything as undefined. Oddly, I got no warning about a missing OST, but I rebuilt that anyway, and after that completed and re-indexed, the syntax checker returned to normal.

Re-closing, as I can now push changes at need. Thanks again for all of your help.

[Scott Wells]

Jason, just so I understand, though, your project against a non-scratch org is still showing Push and Pull as the primary operations against that org? If so, there’s still a bug here.

[Jason Clark]

I believe so - this is what I see in the IC menu for the affected project:

This is what I see in another project, which was originally created with force:project:create --manifest -t emptyand which also uses an SFDX connection to a sandbox:

For my normal IC2 usage, if I’m in a non-source tracked org, I have auto-deploy disabled; I use a keyboard shortcut to Force Save each file when I’m ready to deploy to sandbox. That option was not working at all in the problem project before I created the new DX connection, but it does work afterward.

Let me know if I can provide any other info, but I am up and running now.

[Scott Wells]

Do you mind attaching your .iml file for the project that is still behaving as if against a scratch org?

[Jason Clark]

There’s some client-identifiable info in there, so I just emailed the .iml file to your support email. I think I accidentally sent it from my personal email, but it's the same name. I tagged the issue in the email.