7

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.

  • 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 '18 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 '18 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 '18 at 18:29
3

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.

  • 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 '18 at 13:08
1

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.

  • Same issue here is there a way to mark everything for redeploy? – Scott Morrison Feb 5 at 19:28
  • 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 at 7:11
0

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/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.