[BUG] <Deployment fail at step caching Subtypes with error Cannot read properties of undefined (reading 'map')>

[haolt-toratech]

Is there an existing issue for this?

• [ ✅ ] I have searched the existing issues

Current Behavior

Hello MC Dev Team,

I’m new to both your tool and Salesforce Marketing Cloud, and I would greatly appreciate your help with the issue I’m encountering.

Goal

My goal is to deploy changes to an SQL query file and the content of an automation verification step to Marketing Cloud by running the deploy command, as well as the fixedKeys command for queries and DataExtensions as the files are named using external keys. However, I have been unable to successfully execute these commands. Below is an image of the error I encountered:

Note: A similar error was displayed during different command processes.

Issue

The problem seems to be related to DataExtensions and specifically subtypes such as:

• shared_data
• shared_dataextension
• shared_salesforcedataextension
• synchronizeddataextension

Whenever I run commands that involve processing or caching these subtypes (e.g., mcdev deploy or mcdev fixedKeys), the process fails. This issue occurs for resources such as:

• Automation verification steps
• SQL query files
• DataExtensions themselves

Details

1. Initialy, I was able to retrieve all resources, except dataExtension and query, from my Marketing Cloud instance to local folder using the command:

mcdev retrieve [BU]

I've noticed encountered this error in the log:

error: - Retrieving dataExtension failed: Cannot read properties of undefined (reading 'map')

Interestingly, if I run the command specifically for DataExtensions or query, it retrieves those resource successfully without errors, even the caching step is went through, no error log was displayed:

mcdev retrieve [BU] dataExtension

2. Running the deploy or fixedKey command failed during the caching subtypes step:

deploy command:

mcdev deploy [BU] query "key_name" --fromRetrieve --debug

fixKey command:

mcdev fixKeys [BU] query

Same error was displayed: error: mcdev.deploy failed: Cannot read properties of undefined (reading 'map')

20:10:08 error: mcdev.deploy failed: Cannot read properties of undefined (reading 'map')
20:10:08 debug: TypeError: Cannot read properties of undefined (reading 'map')
at Folder.retrieve (file:///opt/homebrew/lib/node_modules/mcdev/lib/metadataTypes/Folder.js:58:52)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async DataExtension.retrieveSharedForCache (file:///opt/homebrew/lib/node_modules/mcdev/lib/metadataTypes/DataExtension.js:830:24)
at async DataExtension.retrieve (file:///opt/homebrew/lib/node_modules/mcdev/lib/metadataTypes/DataExtension.js:776:38)
at async Deployer._deploy (file:///opt/homebrew/lib/node_modules/mcdev/lib/Deployer.js:347:28)
at async Deployer._deployBU (file:///opt/homebrew/lib/node_modules/mcdev/lib/Deployer.js:248:40)
at async Deployer.deploy (file:///opt/homebrew/lib/node_modules/mcdev/lib/Deployer.js:204:46)
at async Mcdev.deploy (file:///opt/homebrew/lib/node_modules/mcdev/lib/index.js:507:30)

Could you please advise on how to resolve this issue? Specifically:

1. How can I skip or bypass the caching process for these subtypes during commands like deploy or fixedKeys?
2. Are there additional configurations or adjustments I need to make in my config.json or elsewhere to avoid this error?

Expected Behavior

No response

Steps To Reproduce

1. Go to '...'
2. Click on '....'
3. Run '...'
4. See error...

Version

9.5.0

Environment

• OS:
• Node:
• npm:

Participation

• I am willing to submit a pull request for this issue.

Additional comments

No response

[haolt-toratech]

Apologies, I have moved my question to the discussions section as it is more appropriate there. You can close this issue, as it is not a bug in your tool but rather an issue I am seeking help with regarding my SFMC instance.

[JoernBerkefeld]

i wanna treat it as a bug for now. debugging this will require some time and a lot more detailed logs. The best way is to add --api log to your command but that will include a lot more info that might be sensitive.

For now, could you try if the same issue happens if you run mcdev retrieve cred/bu -m folder ?
Judging from the stack trace that might just also fail on your BU. If it does, maybe do try the --api log parameter and then look into the lastest file in /logs/ directory. There will likely be a more detailed error in the returned soap body.

[haolt-toratech]

Hello,

Thank you for your reply.

I was a bit busy last week and just had the chance to test the command.

For your reference, I was able to successfully retrieve folder data using the command without any errors:

mcdev retrieve cred/bu -m folder

However, when I run the deploy command and use the --api log parameter, I am still unable to understand the error.

mcdev deploy cred/bu query query_key --fromRetrieve --debug --api log

The debug output shows that the SOAP API call to retrieve folders (DataFolder) returned an OverallStatus of OK, but no actual data appears in the response body. This suggests that the API call might not have retrieved the expected data.

I suspect the issue could be related to shared_data or shared_dataextension folders. Unfortunately, I haven't been able to trace which specific file in those folder of my instance is causing the error.

Here’s my log (with sensitive information removed):

My log as I removed some sensitive information

API REQUEST >> {
"method": "POST",
"baseURL": "https://[instance].soap.marketingcloudapis.com/",
"url": "/Service.asmx",
"headers": {
"SOAPAction": "Retrieve",
"Content-Type": "text/xml"
}
}
API REQUEST body >>
<Envelope ...>DataFolder...
API RESPONSE body <<
<soap:Envelope ...>soap:BodyOK...</soap:Body></soap:Envelope>
Error: mcdev.deploy failed: Cannot read properties of undefined (reading 'map')

I wonder if there is a way to add a parameter to the command in order to skip caching or retrieving data from these folders when executing commands?

[JoernBerkefeld]

Hmmm, strange.

No, there is no such option because mcdev aims to work across BUs and for that to work needs to resolve sfmc internal (object) ids to readable values during retrieve and back into BU-local (object) ids during deployment. That's what the caching is for: it allows us to get existing folders, including their ids, to find the correct folder ID to include in the request body of your query deployment callout. Thereby, the query will end up in a folder structure on the target BU that mimics what was present on your source BU.

Sometimes, a BU is broken from the start, as in, when it gets provisioned (created), it does not have all necessary default folders. I've seen this happen ONCE so far. My guess is that something similar happened here.

You shared the partial request/response body but that's not detailed enough for an analysis.

next steps:

1. Could you share the full request body (you may reduct your tenant, of course)? API REQUEST body >>
2. Could you also share the full response body? API RESPONSE body <<

Note: If the response body includes sensitive folder names, by all means, replace those words with "xxx" but please leave the rest untouched. Ideally, this should have only cached query folders anyways, making the response rather short. I could then compare it with what's returned for a blank new BU on my test server.

Worst case, we could set up a call in the new year, but I think the logs will suffice.