Cli: Announcement: Rollback of 50.13.3 CLI 7.84.2

[amphro]

We had to roll back yesterday's CLI release because it caused multiple issues for customers. In the spirit of transparency, we want to explain what happened and how we plan to fix it.

As many of you know, we’ve made great progress in open sourcing the CLI (https://developer.salesforce.com/blogs/2020/05/open-sourcing-salesforce-cli.html); stay tuned for a blog post updating the community soon. We’re committed to transitioning the CLI to be fully open-sourced. However, the transition involves moving many commands and builds to multiple public repositories and environments. We are also currently releasing the CLI using both the old and new system.

We haven’t released a new version of the CLI in over a month because of Dreamforce and the holidays. This delay created a release with a lot of changes (https://github.com/forcedotcom/cli/tree/main/releasenotes#50133-january-14-2021---cli-7842). Nonetheless, the release candidate sat in `latest-rc' for over a week to allow for testing, and everything seemed to work correctly in our CI and testing environments.

However, when the CLI was promoted Thursday, January 14, 2021, the archives and plug-in versions were pointing to incorrect and incompatible dependency versions, which caused a variety of regressions. We are still investigating what exactly happened and why our tests didn't catch the issues. We're working to ensure that the new build system will prevent these regressions from happening in the future.

We plan to fix all the dependency issues and build a new latest-rc version next week, and then promote it on Thursday, January 28, 2021.

We apologize for the inconvenience.

[madhoriya22]

Is there a way I can revert back to previous version?

[davisagli]

@amphro Could you clarify what it means that the 50.13.3 release was rolled back? I ran sfdx update this morning, and ended up with version 50.13.3 of the salesforcedx plugin. I had seen this announcement and it took me quite some time to realize that I have the wrong version, since I was expecting that sfdx update would not install a release that was rolled back.

And to echo the previous comment -- now that I have the wrong release, how do I install the previous one?

[sjurgis]

@davisagli follow these instructions then install from here.

What a pain this is...

[aesanch2]

@davisagli @sjurgis I was able to rollback successfully by reinstalling the salesforcedx plugin.

sfdx plugins:install salesforcedx@latest

This put it back to 50.12.

[amphro]

The stable channel, which sfdx update points to, seems to be on different versions... I can look into that a little more.

[gdman]

@amphro please could we have some clarification on which versions are broken and which are ok?

As far as I can tell I currently have 7.84.2 / 50.13.3 which I must have received by auto update as I haven't run SFDX update manually. This is apparently the broken version that was rolled back but appears to be working? (though obviously there may be commands that are broken that I don't use on a day to day basis).

One of my team installed SFDX from the website (https://developer.salesforce.com/tools/sfdxcli) earlier which has 7.83.0 / 50.9.1 - this version is not mentioned as being the broken version but does have the changed sfdx force:auth/sfdx auth changes - which breaks all of our tooling. There are no release notes for this version on the release notes page: https://github.com/forcedotcom/cli/tree/main/releasenotes#50133-january-14-2021---cli-7842. I've run sfdx update manually on his machine and he's been upgraded to the same version as me 7.84.2 / 50.13.3 where sfdx force:auth seems to work.

My findings are that 7.83.0 / 50.9.1 is broken but not mentioned anywhere in this thread and doesn't have any release notes - this is the version being distributed from the Salesforce website. It can be updated to 7.84.2 / 50.13.3 by sfdx update (and will presumably happen automatically after a while?), which is apparently broken but doesn't appear to be for me.

Please could we have some clarification?

[kevanmoothien]

My team and I are not able to Authorize an org on VSCode. Is this issue related?
We are having this issue since friday 22 january. We are on Ubuntu 20.04.

[gdman]

@amphro - is there any update on this?

The version that this post says has been rolled back hasn't, it's still the version users get auto updated to.

[kevanmoothien]

I was able to get it to work by removing the npm version of sfdx-cli and installing the executable directly. This solves the issue we were having during authorize an org where it was not doing the callback to localhost:1717.

If you perform the above solution, you may encounter an issue with port 1717 already open. Simply kill it and restart

lsof -i :1717
kill -9 <PID_HERE>

[gdman]

Thanks for the info @kevanmoothien.

Though, my bigger concern is that Salesforce think 7.84.2 / 50.13.3 has been rolled back and the release notes say it has been rolled back. However, it hasn't been rolled back - it's still the version that auto-updating will install. Including new users going to the Salesforce official website, downloading SFDX and installing it - that installs a more broken version 7.83.0 / 50.9.1 that doesn't have any release notes then auto updates to 7.84.2 / 50.13.3.

As it happens 7.84.2 seems to be ok for me but I have a large team of developers using SFDX that will all be on this version. I want to be prepared for any issues and know if I need to get them all to manually install an older version (which will be very painful). That's where I'm hoping @amphro can help.

[amphro]

Hey @gdman - apologize for the delay in communication. Here is where we stand:

There are four different install paths:

1. NPM
2. Unversioned archives
3. Versioned archives
4. The installers

The first two experienced the problem and have been rolled back. In other words, the NPM latest tag now points to a previous version and the unversioned archives have been overwritten with the previous version.

The third one, which is used for the auto-update, apparently does not have the same problem. There are stable channel files that point to a version that tells the CLI which version to auto-update to. The time we update those files is in our build to a new version. i.e. roll forward. I looked into rolling those back and I really don't want to update those pointers/shas manually if I don't have to. It seems easy to mess them up.

The fourth one, I didn't realize the installers were still on 7.83.0 / 50.9.1 - those usually get updated each week too. What is broken with that version? That version should have been stable.

Assuming that the version is working for people who are auto-updated, I'm not going to change them and they will be updated next week.

Yes, you heard that right, next week. We can't release tomorrow for some reasons outside our control. This means we will update everything next Friday. We will still be publishing the latest-rc npm channels tomorrow.

[amtrack]

@amphro While cleaning up the npm versions, is it possible to deprecate/unpublish
47.15.1 (a year ago)?
This version seems to not follow any of your versioning patterns.

Background: I'm currently on [email protected] which appeared to me to have been the latest stable version for the past weeks, but npm (respectively npm-check and renovatebot) are trying to update to 47.15.1 😃.

[gdman]

@amphro - Thanks for all the information, that's really useful.

We found the 7.83.0 / 50.9.1 version has the change to move sfdx force:auth:* to sfdx auth:* but doesn't have backwards compatibility so the sfdx force:auth:* commands don't work - this breaks our build scripts. 7.84.2 / 50.13.3 fixes this so I can just tell any users who install from the website to run sfdx update.

Thanks again for the response.

[amphro]

@amtrack I noticed that a while back too, but I can't unpublish it because of NPM rules. I didn't even know or think to try deprecating the version. I'll give it a go.