force:source:deploy -x manifest/package.xml failing #1112
Comments
|
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. |
WillieRuemmele
added
plugin-source
and removed
investigating
|
I'm getting a similar issue after fully reinstalling sfdx from trying to fix the snafu of the "no such file or directory" bug - and now I'm getting: sfdx force:source:deploy -u MySandbox -x manifest/package.xml -w 60 These deploys have worked fine in the past. Since this is a fresh install how do I work around it? |
|
@WillieRuemmele thanks for the quick reply! I ran through and checked the objects folder. I was hoping I'd be able to attempt to deploy the objects in chunks but no such luck. I'll post any updates here as I go through and troubleshoot. |
|
It looks like |
|
@AndrewRayCode you can definitely install an older version if you need to get back to work right away (and turn off auto-update). URLs here: https://github.com/forcedotcom/cli/blob/main/releasenotes/README.md#51140-may-27-2021---cli-71030 If you're able to share your repo where the error is happening, or isolate it to a particular component, that helps us fix the bug in the current version. |
|
It seems like there's something else that's wrong with deploying with the -x flag. I can deploy all the other source (except the Objects) in my project without errors using VS Code (right click + Deploy Source to Org) or with the sfdx force:source:deploy -p path/to/folder. When I deploy with Here's the --dev-debug error: |
|
@AndrewRayCode I tried going to the json file in the link you added but I'm getting an Access Denied error on the page for sfdx-linux-arm-tar.xz.json. |
|
@tetter36 that's a typo--it should be @jshackell-sfdc FYI for RN and docs. |
|
Any chance y'all have the standard Task object in your repo? We've seen elsewhere an error with that. You can try just deploying that object ( |
mshanemc
added
the
more information required
|
I'm still getting the same issue even when removing all objects from the package.xml file to deploy. It deploys correctly when I run sfdx force:source:deploy -p force-app when I have the forceignores for **/objects/* Here's my package.xml file that no longer works even with the CustomObject removed: I also tested the VS Code deploy with each of the listed folders and they all deployed without errors. |
no-response
bot
removed
the
more information required
|
Hello, I have same problem. My logs: |
|
I'm getting the similar issue when I'm trying to use: |
|
@EgorBosolyho to make sure I understand, |
|
I found my first issue, which was that there are *.cls files inside an object folder. After moving those, I'm now getting
Not sure why yet. @mshanemc you released breaking API changes to sfdx (like requiring certain files not to be in certain folders) with no warning, and rolling back doesn't fix it. Would you consider reverting the recent feature work and cut a new sfdx version until you're able to triage the root cause of these issues? This incident has been going on for several days now, still no formal messaging from the team |
Yes, it is.
|
|
I found two issues (so far):
It doesn't look like these changes are mentioned in the release notes https://github.com/forcedotcom/cli/blob/main/releasenotes/README.md, except this which you have to admit is ironic considering the current issues:
I'm now getting additional Please consider rolling back the latest release and triaging these issues! |
|
At least one more breaking change with no messaging / warning, I found that we have line in our package.xml like: and on disk, the report is in the folder It appears the source of this breaking change is now requiring the full relative path from |
@AndrewRayCode apologies for the breaking changes. We've heard from a few people that had non very non-standard folder structures (like your example of classes inside object folders). We didn't have any sample projects with structures like that to test with, and wouldn't have imagined it would have worked on the old version, either. We didn't/don't intend to support that structure. We did provide notice of the beta via a pinned issue #1057 for ~6 weeks to let users experiment with and report bugs in the new version of the source commands and announced the change in the release notes. https://github.com/forcedotcom/cli/blob/main/releasenotes/README.md#71120-august-4-2021 We've been monitoring the exception telemetry around this release and haven't seen any increase to exceptions for the Can you say more about what makes using |
|
@EgorBosolyho @zankoav I know you probably can't provide your objects folder so we can experiment with |
|
Another breaking change found blocking deploys, We had a MyGroup.group-meta.xml file in queues/ instead of groups/ which explains the cryptic error: I'm not sure why all of these breaking change undocumented parse-time errors happen at the end of a deploy and not at the start, it's a long cycle to wait. This appears to be an uncaught runtime parse error which could be much more intuitive especially since you've consciously chosen to enforce new project structures.
@mshanemc thanks, would love to see the postmortem on this one and how these breaking changes were released (including the one where sfdx self-deletes itself and requires a full reinstall) with no messaging and people having to hunt around github tickets to understand what's going on. Given these tickets have been open for almost a week now with no official messaging nor resolutions I think it would be a good gesture to the dx community to look into the rollout strategy for things like these.
I tried manually installing 7.110 and below and still got the same blocking issues on deploys. sfdx doesn't seem to do clean deterministic installs so I'm not sure why downgrading didn't work. Releasing undocumented breaking changes with no downgrade strategy is really painful dx. |
|
I'm really looking forward to debugging my next blocking deploy error: |
|
Two additional breaking changes from above:
|
|
These errors persist after @shetzel Can you please advise how to downgrade sfdx, as there haven't been any downgrade instructions during this incident yet? |
|
Another breaking change: We had |
|
@AndrewRayCode the sfdx plugins:install [email protected] doesn't work. I tried it before submitting this bug initially. You'll have to remove the sfdx version you have and then install it from one of the links that @mshanemc provided above. I was able to work around the issue for now with my GitLab CI/CD pipeline by not upgrading sfdx. This allowed me to successfully deploy my code as is with no errors. |
@mshanemc , unfortunately, I can't provide you with our metadata, but I can do any local testing you need. objects folder info - |
|
More breaking changes:
Normally for libraries with such traction, backwards incompatible breaking changes are released with deprecation warnings for developers. You shouldn't expect developers to check the sfdx github every day looking for beta releases. Could you please add official messaging around the issues with this release? You introduced so many breaking changes at once. |
|
The broken report issue may be that the relative folder path in the source isn't listed as its own standalone folder and reportFolder. |
|
@AndrewRayCode thanks for all the findings...the nested folders change for reports/dashboards/emailTemplates is a nice catch. I think that's all the same bug. You brought up a good question--what's your preferred method for hearing about upcoming CLI changes? We've discussed putting occasional notices in the stdout for non-CI use cases...would that be more helpful than just using release notes and github? We did get a report of the empty-folder or invalid LWC bug (it'll bite empty/invalid Aura, too): #1099 |
|
@shetzel @WillieRuemmele we've got a volunteer for some local test/debug. Thanks, @EgorBosolyho |
@mshanemc from looking at the versions on npm, sfdx has been out for 4 years, and for 4 years it's supported non-standard project structure. In a single release you had dozens of breaking changes, including API changes. We're in day 7 of this incident/outage, it doesn't seem like it's being taken seriously. Users are left to fend for themselves with information scattered between Github, Salesforce Groups, and Stackexchange, and there's been no official support from the platform team. Even the rollback process is broken and the "right" way to rollback is hidden in Github comments (also how do you rollback vscode version vs terminal version?). I think it's up to your team to run a full post mortem on this and figure out how to improve developer messaging, and have the difficult conversation about sfdx auto-updating by default. Given there's no proper channels for it now, maybe communicate on every channel you have, to make sure folks see it? Including another sfdx update that uses a post-install step, or a one-time warning that users have to confirm, that there are massive changes in this version? And updating the release notes to document the dozens of breaking changes? Just some thoughts - I think this is really something to triage as an all-hands-on-deck incident. These are just my thoughts, I don't know how your team wants to handle it, I just hope you take it seriously and do lots of formal messaging around it, given that this is the core tool of salesforce dx. |
|
Hi @tetter36 @EgorBosolyho @zankoav @AndrewRayCode thanks for the continued help, This thread is quickly growing to include multiple different bugs. In order to clarify things for our team, and other users, I'm going to break this thread up into the different bugs that I see by reading through it. I'll be copy/pasting things from here into their own threads if you feel that I've missed any bugs feel free to create a new issue |
|
I've seen this issue as well, and I've isolated it to an index on a BigObject, e.g., |
|
Hi @mshanemc , I have tested this in my project, so if I delete all |
|
this should be fixed in the latest-rc build of the cli Please let us know if you're still seeing this in |
|
We have a few more errors related to non-basic folder structure and latest cli `7.116.0
|
@mshanemc my id issue was due to the bigObjectIndex as well. After I removed the index metadata file, everything worked correctly. @SCWells72 great find! |
|
Tips that saved a sfdx project of mine (and probably all the others)
If you have broken flexipages, it's because of broken ascending compatiblity -> https://salesforce.stackexchange.com/questions/357206/problem-when-deploying-flexipages-on-winter-22-org-the-xxxx-component-in To fix your flexipages, you can either update all your XMLs one by one, or use the following sfdx-hardis command
Edit: and this is not over... lots of items in folders are not found whereas they ARE in sfdx folders >_<
Same here than for @steals |
|
This was fixed in latest v7.120.0, release notes: |
Summary
I'm getting deploy errors after updating to v. 7.112.*
Everything worked on v 7.111.*
I'm getting this error when attempting to run sfdx force:source:deploy -x manifest/package.xml:
*** Deploying with SOAP API ***
ERROR running force:source:deploy: Component conversion failed: Cannot read property 'id' of undefined
I've tried running with verbose flag, run in VS Code but I'm not getting any more info than "Cannot read property 'id' of undefined."
Steps To Reproduce:
Navigate to a repo with a manifest. run sfdx:force:source:deploy -x path/to/package.xml
Expected result
Should run the deployment without errors.
Actual result
Getting error:
*** Deploying with SOAP API ***
ERROR running force:source:deploy: Component conversion failed: Cannot read property 'id' of undefined
System Information
{
"cliVersion": "sfdx-cli/7.112.1",
"architecture": "darwin-x64",
"nodeVersion": "node-v14.17.4",
"pluginVersions": [
"@oclif/plugin-autocomplete 0.3.0 (core)",
"@oclif/plugin-commands 1.3.0 (core)",
"@oclif/plugin-help 3.2.2 (core)",
"@oclif/plugin-not-found 1.2.4 (core)",
"@oclif/plugin-plugins 1.10.1 (core)",
"@oclif/plugin-update 1.4.0-3 (core)",
"@oclif/plugin-warn-if-update-available 1.7.0 (core)",
"@oclif/plugin-which 1.0.3 (core)",
"@salesforce/sfdx-plugin-lwc-test 0.1.7 (core)",
"@salesforce/sfdx-trust 3.6.0 (core)",
"alias 1.1.10 (core)",
"apex 0.2.3 (core)",
"auth 1.7.1 (core)",
"config 1.2.14 (core)",
"custom-metadata 1.0.12 (core)",
"data 0.6.0 (core)",
"generator 1.1.7 (core)",
"limits 1.2.1 (core)",
"org 1.6.7 (core)",
"salesforce-alm 52.2.3 (core)",
"schema 1.0.8 (core)",
"sfdx-cli 7.112.1 (core)",
"source 1.0.6 (core)",
"telemetry 1.2.3 (core)",
"templates 52.1.0 (core)",
"texei-sfdx-plugin 1.10.1",
"user 1.4.0 (core)"
],
"osVersion": "Darwin 20.5.0"
}
The text was updated successfully, but these errors were encountered: