11

Something funky happening with SFDX CLI. Earlier today, I had an unexpected restart on my Mac -- not sure why, but I've run an anti-virus scan and appears to be clean. Restarted a couple of times.

Now, SFDX not seeing a status difference between my source and my scratch org. I was able to push a layout, but the class had an error (invokable classes can only have one parameter). I fixed that and tried to push again, but got the "No Results Found" error. If I run sfdx force:source:status, I get "No Results found".

I double checked the scratch org -- the class isn't there, but sfdx doesn't see a difference between my source and scratch.

I thought maybe I had mistakenly edited the mdapioutput class (that happened to me once before), but I don't have a current mdapioutput set of files, so it's not that.

Wondering if something got corrupted, if so, what would it be, and how can I check it/fix it?

UPDATE: I was able to fake it out by creating another new class that did nothing, but when I ran sfdx force:source:status, it showed up, along with the real class I wanted to move. I was able to push them both, then delete the dummy class.

Improve this question
3
  • Good that you found a workaround. I'm resigned to creating a new scratch org as the workaround that fixes everything...
    – Keith C
    Apr 25, 2018 at 10:38
  • This seems to be an issue with sfdx. My suggestion was going to be what you did. If you even just add a comment or newline in one of the files it seems to fix it.
    – Zack Walton
    Apr 30, 2018 at 16:49
  • +1 for your workaround. Make it an answer and I'll upvote it. Wasted an hour trying to get DX to recognize a new class, but adding another class fixed it. Interestingly, you must push the dummy class and then remove- removing it before push caused DX to lose track of the "real" new class again too.
    – Jason Clark
    Aug 1, 2018 at 18:29

4 Answers 4

Reset to default
6

UPDATE: I was able to fake it out by creating another new class that did nothing, but when I ran:

sfdx force:source:status

It showed up, along with the real class I wanted to move. I was able to push them both, then delete the dummy class.

Improve this answer
1
  • This did work for me, but then I still had a mistake in the class I wanted to save, and after correcting I got the same issue again. This was with a new class, seems DX is a bit flakey in this area.
    – Matt Lacey ♦
    Sep 21, 2018 at 13:08
4

Another option is to use sfdx:force:deploy instead of sfdx:force:push to get the source into your target org, once it's deployed you should be able to then use push normally

sfdx force:source:deploy -u [username/alias] -p force-app/
Improve this answer
1
  • Deploy has the same behavior when this situation is encountered.
    – Shanerk
    Oct 20, 2020 at 16:54
3

I've got the same issues as you. Sometimes when there is compilation error in the component, it's not deployed but Salesforce registers it as up to date with scratch org. It's not possible to deploy it anymore until you make a change.

One workaround is to make a white space change in the class, dx should notice the difference and let you deploy it.

In my case, I've had to migrate fields from other (non-dx) environment. Deployment failed, but DX still thought fields are on scratch org :) I've had to delete fields locally, "push" deletion and then restore the fields and push again.

Another irritating thing I've encountered - deployment to new org failed...partially. Some classes have been deployed, others did not and I have not way to say which ones are not on the org.

Improve this answer
2
  • Same issue here is there a way to mark everything for redeploy?
    – Scott Morrison
    Feb 5, 2019 at 19:28
  • 1
    Check what's your username by issuing sfdx force:user:display, then delete content from ./sfdx/orgs/USERNAME/sourcePathInfos.json This file has array of metadata, replace it with empty array [].
    – pkozuchowski
    Feb 7, 2019 at 7:11
0

The only good (e.g. deterministic) "workaround" is to open developer console and copy-and-paste your code from the local into the resource file in your scratch org/sandbox. This will immediately give you insight into the compile errors that are the root cause of this issue and allow you to resolve them. Once you do that and copy the fixes back into your local workspace, the cli push and cli deploy functions will work again as expected.

This is a pretty awful bug in the CLI however. Getting a success status when in fact the push failed to update the code is extremely frustrating.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .