Infinite loop in sfdx force:source:manifest:create ? #2445
Comments
github-actions
bot
added
the
validated
|
Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support. |
|
The packaging plugin is configured as a jit plugin in @salesforce/cli. Maybe this means it is downloaded only when needed? And maybe that is why it is now under (user) and not (core)? |
|
@AllanOricil I anticipated and downloaded it before both locally and in my CI/CD pipeline / docker images npm install @salesforce/cli --global
sf plugins install @salesforce/plugin-packaging |
Always specify a version when installing any package. 1.23 has been patched recently and that might be causing the issue. Which is good because you probably found a bug 🐛 |
|
And this package is in https://github.com/salesforcecli/plugin-deploy-retrieve anyway ^^ |
Nah, can't update all pipelines of all clients everytime there is a new version :D But latest versions are supposed to be stable, and usually are :D |
What if you control on ur side a docker image with all build dependencies. Then your clients will use :latest but you are responsible for not updating your latest build image without testing its build dependencies. |
|
@nvuillam that plugin was updated 3 days ago 
its core package was bumped https://github.com/salesforcecli/plugin-deploy-retrieve/releases/tag/1.17.8 |
|
@mdonnalley do you have some clue or workaround, as it seems to work with sfdx-cli and not @salesforce/cli , except rolling back to sfdx-cli ? :/ |
|
what if you downgrade this plugin only and test it again just to tell us if the issue is fixed. If it does fix the problem, then we could open a PR to downgrade the core package again and release a patch for the plugin-deploy-retrieve package until a proper bug fix is released |
|
@AllanOricil I was able to narrow it down to SDR v9.7.7 and this commit: forcedotcom/source-deploy-retrieve@26aef11 It looks like a performance issue in this line: https://github.com/forcedotcom/source-deploy-retrieve/blob/26aef11495835caa7735fb1b96c6ab591c95ea7e/src/collections/decodeableMap.ts#L72 |
|
@jayree and plugin-deploy-retrieve is using 9.7.2 and it allows patches 
https://github.com/salesforcecli/plugin-deploy-retrieve/blob/1.17.8/package.json#L13 |
|
I think this happens because sf uses yarn when running sf update. According to chatgpt, yarn upgrades indirect dependencies whereas npm does not. |
|
@nvuillam could you open the root of the sfdx cli package and run |
|
@AllanOricil the |
|
@jayree are u really sure that the error is due to those changes? If yes, I can open a PR downgrading the package version to one before that change Or since u found the root cause, fo ahead and get the package version of the plugin that has the source-retrieve version before 9.7.7, then open a PR in @salesforce/cli |
… for SF cli bug Related bug: forcedotcom/cli#2445
… for SF cli bug (#412) * Downgrade @salesforce/plugin-deploy-retrieve to v1.17.6 as workaround for SF cli bug Related bug: forcedotcom/cli#2445 * Dockerfile fix * [Mega-Linter] Apply linters fixes --------- Co-authored-by: nvuillam <[email protected]>
|
Workaround: downgrade plugin-deploy-retrieve to v1.17.6
But it still takes 10-15mn to call the command instead of the usual 30 seconds, and on really big orgs it still hangs forever, so I suspect a memory leaks or something like that |
@AllanOricil yes, I've tested it here: jayree/sfdx-plugin-manifest@b6493b9 with the pinned SDR version |
|
cool. We are all waiting for your PR! good job |
|
https://github.com/forcedotcom/source-deploy-retrieve/compare/9.7.8..9.7.6 in case someone wants to check the diffs between both releases |
|
I need a working dockerfile for sfdx-hardis image :/ The current workaround does not the job, it's still dramatically slow , or hanging forever npm install @salesforce/cli --global
sf plugins install @salesforce/plugin-packaging
sf plugins install @salesforce/[email protected]Would anyone have the magic command to have the working version of source-deploy-retrieve ? |
|
@jayree couldn't the reason also be releated to this bump? 
|
|
nope, it does not interefere on anything https://github.com/forcedotcom/kit/compare/3.0.11..3.0.9 |
|
@AllanOricil > @jayree 's plugin is @jayree/sfdx-plugin-manifest, @salesforce/plugin-manifest does not exist :( |
|
@nvuillam try this in the root of the cli
or
|
|
@AllanOricil maybe i can add a --global or try to find the good CWD ? |
|
follow these steps 
Then install 9.7.6 
|
Wait for fix of forcedotcom/cli#2445
|
@AllanOricil its not just on my computer, it's in a dockerfile, on azure pipelines scripts, etc... |
|
@nvuillam you could run these steps on your docker image. It is just another build dependency as any other. |
|
Doesn't work with these exacts commands, it would work if they were platform / context agnostic :/ But many many thanks for trying, and thanks to @jayree ! |
|
@nvuillam why exactly wouldn't this work on your docker image? I can't see it workaroundfix.sh #!/bin/bash
cli_path=$(which sf | sed 's/\/bin\/sf/\/lib\/node_modules\/@salesforce\/cli/g')
cd $cli_path
npm install @salesforce/[email protected] --save-exactIn your dockerfile (your build environment, which is agnostic to the platform) run the script after setting up sfdx ...
COPY . ./workaroundfix.sh
RUN chmod +x ./workaroundfix.sh
RUN ./workaroundfix.sh
RUN rm ./workaroundfix.sh |
|
@AllanOricil you're a genius ! |
|
I'm not. I just have no social life 😅 |
forcedotcom/cli#2445 AllanOricil is a genius !
|
Thanks @nvuillam @AllanOricil and @jayree for reporting and all the detective work on this! Very sorry about the regression and we're getting this fixed in production asap. |
|
@shetzel any idea about when it will be released in salesforce/cli@latest ? (just to know if I have to continue building workarounds in sfdx-hardis or not to unlock my clients) |
|
PR 1101 is nearly finished with CI tests. Once merged it's just a few minutes to publish. Then we'll get the CLI e-release process going. Overall I'd estimate about an hour, hopefully less. |
|
@shetzel many thanks for the info :) |
|
SDR v9.7.9 has the revert. New CLIs (and all artifacts, including docker images) are being built and I'll post here when they are available. Thanks for your patience and apologies for the regression! |
|
@shetzel i'm in the starting blocks to make a new sfdx-hardis release, thanks ;) |
|
|
* Again a workaround for SF bug forcedotcom/cli#2445 AllanOricil is a genius ! * Back to normal since forcedotcom/cli#2445 is fixed * [Mega-Linter] Apply linters fixes --------- Co-authored-by: nvuillam <[email protected]>
|
@shetzel |
|
million lifes were saved |
|
ma heroes |
|
Apologies for not jumping on this sooner. Kudos to @nvuillam, @AllanOricil, and @jayree for pinpointing the problem code. Now I need to figure out a better solution for my DecodableMaps PR... |
|
S**t happens sometimes to any of us ^^ |
|
@nvuillam Tell Pablo to unblock me on LinkedIn 🤣 |
Since today, on many orgs (maybe all of them), the command
sfdx force:source:manifest:createnever returns anything (after 2h !) and it's not even possible to stop it with CTRL+C when trying locally.Has there been any updates on the related commands ?
It seems it works with sfdx-cli but not with @salesforce/cli , whereas packaging plugin is previously installed locally and in CI context ( Azure pipelines )
Has someone seen similar issues ?
It blocks the sfdx-hardis based CI/CD pipelines of major clients 😢
Command :
sfdx force:source:manifest:create --manifestname package-full.xml --outputdir manifest --includepackages managed,unlocked --fromorg [email protected]My setup
{ "cliVersion": "@salesforce/cli/2.6.7", "architecture": "win32-x64", "nodeVersion": "node-v18.15.0", "osVersion": "Windows_NT 10.0.22621", "shell": "C:\\Program Files\\Git\\usr\\bin\\bash.exe", "rootPath": "C:\\Users\\33614\\AppData\\Roaming\\npm\\node_modules\\@salesforce\\cli", "pluginVersions": [ "@oclif/plugin-autocomplete 2.3.6 (core)", "@oclif/plugin-commands 2.2.23 (core)", "@oclif/plugin-help 5.2.17 (core)", "@oclif/plugin-not-found 2.3.37 (core)", "@oclif/plugin-plugins 3.2.7 (core)", "@oclif/plugin-search 0.0.22 (core)", "@oclif/plugin-update 3.1.32 (core)", "@oclif/plugin-version 1.3.8 (core)", "@oclif/plugin-warn-if-update-available 2.0.48 (core)", "@oclif/plugin-which 2.2.31 (core)", "@salesforce/cli 2.6.7 (core)", "apex 2.3.11 (core)", "auth 2.8.13 (core)", "data 2.5.7 (core)", "deploy-retrieve 1.17.5 (core)", "info 2.6.39 (core)", "limits 2.3.31 (core)", "login 1.2.28 (core)", "org 2.10.3 (core)", "packaging 1.23.2 (user)", "schema 2.3.23 (core)", "settings 1.4.26 (core)", "sobject 0.2.6 (core)", "source 2.10.32 (core)", "telemetry 2.3.1 (core)", "templates 55.5.10 (core)", "trust 2.6.3 (core)", "user 2.3.29 (core)", "sfdmu 4.30.0 (user)", "sfdx-essentials 2.12.0 (user)", "sfdx-git-delta 5.25.2 (user)", "sfdx-hardis 4.2.3 (link) C:\\git\\pro\\sfdx-hardis2", "texei-sfdx-plugin 1.17.3 (user)" ] }The text was updated successfully, but these errors were encountered: