forcedotcom / cli

Salesforce CLI
https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/
BSD 3-Clause "New" or "Revised" License
494 stars 78 forks source link

"sfdx force:source:manifest:create --fromorg" error "The "path" argument must be of type string. Received an instance of Object" #1492

Closed RupertBarrow closed 2 years ago

RupertBarrow commented 2 years ago

Summary

% sfdx force:source:manifest:create --fromorg xxxxx-prod
ERROR running force:source:manifest:create: The "path" argument must be of type string. Received an instance of Object

Steps To Reproduce:

Repository to reproduce: this is in production of a customer's org

NOTE: If your issue is not reproducable by dreamhouse-lwc, i.e. requires specific metadata or files, we require a link to a simple Salesforce project repository with a script to setup a scratch org that reproduces your problem.

  1. set up SFDX project for the customer's production org
  2. auth into the org with SFDX, setting alias to xxxxx-prod
  3. run the command : sfdx force:source:manifest:create --fromorg xxxxx-prod

Expected result

Should produce a ./package.xml manifest file

Actual result

Error message : ERROR running force:source:manifest:create: The "path" argument must be of type string. Received an instance of Object

System Information

% sfdx version --verbose --json { "cliVersion": "sfdx-cli/7.148.3", "architecture": "darwin-x64", "nodeVersion": "node-v16.14.2", "pluginVersions": [ "@oclif/plugin-autocomplete 0.3.0 (core)", "@oclif/plugin-commands 1.3.0 (core)", "@oclif/plugin-help 3.3.1 (core)", "@oclif/plugin-not-found 1.2.6 (core)", "@oclif/plugin-plugins 1.10.11 (core)", "@oclif/plugin-update 1.5.0 (core)", "@oclif/plugin-warn-if-update-available 1.7.3 (core)", "@oclif/plugin-which 1.0.4 (core)", "@salesforce/sfdx-plugin-lwc-test 0.1.7 (core)", "alias 2.0.0 (core)", "apex 0.11.0 (core)", "auth 2.0.2 (core)", "community 1.1.4 (core)", "config 1.3.30 (core)", "custom-metadata 1.1.0 (core)", "data 0.6.13 (core)", "generator 1.2.2 (core)", "info 2.0.0 (core)", "limits 2.0.0 (core)", "org 1.11.2 (core)", "salesforce-alm 54.2.0 (core)", "schema 2.0.0 (core)", "sfdx-cli 7.148.3 (core)", "sfpowerkit 4.2.5", "shane-sfdx-plugins 4.43.0", "├─ @mshanemc/plugin-streaming 1.1.7", "└─ @mshanemc/sfdx-sosl 1.1.0", "signups 1.0.0 (core)", "source 1.9.3 (core)", "telemetry 1.4.0 (core)", "templates 54.3.0 (core)", "trust 1.1.0 (core)", "user 1.7.1 (core)" ], "osVersion": "Darwin 20.6.0" }

Additional information

0) This is an org which dates back to 2011

1) I managed to produce a generated package.xml with the sfpowerkit command, which did produce a warning message : % sfdx sfpowerkit:org:manifest:build -u terredeliens-prod -x -o manifest/generated/package-sfpowerkit.xml

sfpowerkit -- The DX@Scale Developer Toolkit - Version:4.2.5 - Release:April 22

Error in adding Type [object Object] member.fileName.includes is not a function Mainfest manifest/generated/package-sfpowerkit.xml is created successfully

2) sfdx force:source:manifest:create --fromorg xxx-prod --loglevel=debug produced this output log : see attached debug.log debug.log

github-actions[bot] commented 2 years ago

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.

mshanemc commented 2 years ago

@RupertBarrow I'm not able to repro this. I do get a bunch of connection errors, but also get what looks like a valid package.xml when it finishes.

I tried it with a hyphen in the alias and that didn't seem to matter. Anything else I should try?

aheber commented 2 years ago

I do get this behavior, Windows OS.

sfdx force:source:manifest:create --fromorg prod
ERROR running force:source:manifest:create:  The "path" argument must be of type string. Received an instance of Object
sfdx plugins --core
@oclif/plugin-autocomplete 0.3.0 (core)
@oclif/plugin-commands 1.3.0 (core)
@oclif/plugin-help 3.3.1 (core)
@oclif/plugin-not-found 1.2.6 (core)
@oclif/plugin-plugins 1.10.11 (core)
@oclif/plugin-update 1.5.0 (core)
@oclif/plugin-warn-if-update-available 1.7.3 (core)
@oclif/plugin-which 1.0.4 (core)
@salesforce/sfdx-plugin-lwc-test 0.1.7 (core)
alias 2.0.0 (core)
apex 0.11.0 (core)
auth 2.0.2 (core)
community 1.1.4 (core)
config 1.3.30 (core)
custom-metadata 1.1.0 (core)
data 0.6.13 (core)
generator 1.2.2 (core)
info 2.0.0 (core)
limits 2.0.0 (core)
org 1.11.2 (core)
salesforce-alm 54.2.0 (core)
schema 2.0.0 (core)
sfdx-cli 7.148.3 (core)
sfdx-devops 0.4.6
sfdx-heber 0.0.2
sfdx-typegen 0.6.2
sfpowerkit 4.2.5
shane-sfdx-plugins 4.43.0
├─ @mshanemc/plugin-streaming 1.1.7
└─ @mshanemc/sfdx-sosl 1.1.0
signups 1.0.0 (core)
source 1.9.3 (core)
telemetry 1.4.0 (core)
templates 54.3.0 (core)
trust 1.1.0 (core)
user 1.7.1 (core)
iowillhoit commented 2 years ago

Hello @RupertBarrow, @aheber, I am also unable to reproduce this (using sfdx 1.149.1). Could one of you please provide detailed reproduction steps using Dreamhouse or some other demo org you are able to share with us? Thank you

RupertBarrow commented 2 years ago

Hi @mshanemc @iowillhoit As mentioned by email, this error (in my case) is probably due to something in my customer's old org from 2011. I am pulling from their production org so, obviously, cannot reproduce in another org, and of course not in a scratch org or sandbox.

If I share access to this customer's production org with Salesforce Support, could you then try to reproduce this issue from there, somehow ?

aheber commented 2 years ago

Here is the component object that is being passed around.

{
  createdById: '005[userid]',
  createdByName: 'Anthony Heber',
  createdDate: '1970-01-01T00:00:00.000Z',
  fileName: { '$': { 'xsi:nil': 'true' } },
  fullName: '_Default',
  id: '',
  lastModifiedById: '005[userid]',
  lastModifiedByName: 'Anthony Heber',
  lastModifiedDate: '1970-01-01T00:00:00.000Z',
  namespacePrefix: '',
  type: { '$': { 'xsi:nil': 'true' } }
}

You can see the resolved fileName, that is what isn't getting parsed correctly on this codepath.

Here is the error trace:

sfdx force:source:manifest:create --fromorg prod
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received an instance of Object
    at new NodeError (node:internal/errors:371:5)
    at validateString (node:internal/validators:120:11)
    at extname (node:path:837:5)
    at extName (C:\Users\[username]\AppData\Local\sfdx\client\7.148.3-dbf0a7b\node_modules\@salesforce\source-deploy-retrieve\lib\src\utils\path.js:30:38)
    at ConnectionResolver.resolve (C:\Users\[username]\AppData\Local\sfdx\client\7.148.3-dbf0a7b\node_modules\@salesforce\source-deploy-retrieve\lib\src\resolve\connectionResolver.js:39:87)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Function.fromConnection (C:\Users\[username]\AppData\Local\sfdx\client\7.148.3-dbf0a7b\node_modules\@salesforce\source-deploy-retrieve\lib\src\collections\componentSet.js:141:26)
    at async Function.build (C:\Users\[username]\AppData\Local\sfdx\client\7.148.3-dbf0a7b\node_modules\@salesforce\source-deploy-retrieve\lib\src\collections\componentSetBuilder.js:90:40)
    at async createManifest (C:\Users\[username]\AppData\Local\sfdx\client\7.148.3-dbf0a7b\node_modules\@salesforce\plugin-source\lib\commands\force\source\manifest\create.js:51:30) {
  code: 'ERR_INVALID_ARG_TYPE'
}

Adding some additional debugging it looks like this is connected to the SynonymDictionary that we have setup. (I passed the metadata type along with the output)

aheber commented 2 years ago

I'll take a pass as a PR for this and link it. Shouldn't be too bad but I might not think about all the edge cases.

cristiand391 commented 2 years ago

This should be fixed in latest 7.151.1, see release notes: https://github.com/forcedotcom/cli/tree/main/releasenotes/sfdx#71511-may-19-2022-stable

Thank you all for reporting (and contributing 😃 )!

AltiusRupert commented 2 years ago

Hi, on one old org, this has fixed my issue. On another, it is still crashing :

% sfdx force:source:manifest:create --fromorg=xxx-prod --loglevel=debug
ERROR running force:source:manifest:create:  Cannot read properties of undefined (reading 'name')
RupertBarrow commented 2 years ago

Hi Shane ! Well, it’s certainly due to the old org we are dealing with.

If I set up a test admin user on this prod org, would you be willing to reiterate your test ?

Thanks for your support, Best regards,

Le 2 mai 2022 à 19:24, Shane McLaughlin @.***> a écrit :

@RupertBarrow https://github.com/RupertBarrow I'm not able to repro this. I do get a bunch of connection errors, but also get what looks like a valid package.xml when it finishes.

I tried it with a hyphen in the alias and that didn't seem to matter. Anything else I should try?

— Reply to this email directly, view it on GitHub https://github.com/forcedotcom/cli/issues/1492#issuecomment-1115147345, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTAP56UJKFASW6VAHLUCLDVIAFT5ANCNFSM5UZ6VATA. You are receiving this because you were mentioned.

ashokkalluri commented 1 year ago

Hi, on one old org, this has fixed my issue. On another, it is still crashing :

% sfdx force:source:manifest:create --fromorg=xxx-prod --loglevel=debug
ERROR running force:source:manifest:create:  Cannot read properties of undefined (reading 'name')

@RupertBarrow : were you able to fix this issue?