Every *.yml file is now inferred as External Service Registration after enabling metadata decomposition

[Damecek]

Summary

After enabling External Service metadata decomposition using
sf project convert source-behavior --behavior decomposeExternalServiceRegistrationBeta --target-org carvago-prod,
sf project deploy start started treating every *.yml file in the project as an ExternalServiceRegistration. This causes conversion errors for YAML files that are not External Services (for example YAML used to generate Custom Metadata).

Steps To Reproduce

1. Create a project:

   sf project generate --name ext-svc-decomposition-issue
   cd ext-svc-decomposition-issue

2. Create a folder for Custom Metadata and add any YAML file that is not an External Service, for example:

   mkdir -p force-app/main/default/customMetadata/stateTransition
   cat > force-app/main/default/customMetadata/stateTransition/financing_transitions.yaml << 'EOF'
   # example yaml used for generating custom metadata records
   someKey:
     someField: someValue
   EOF

3. Enable External Service metadata decomposition as per the documentation
   (https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_decomposed_md_types.htm):

   sf project convert source-behavior      --behavior decomposeExternalServiceRegistrationBeta      --target-org <your-org>

4. Try to deploy the project:

   sf project deploy start --source-dir force-app --target-org <your-org>

5. The deploy fails with an error similar to:

   Error (ConversionError): Component conversion failed: ENOENT: no such file or directory, open '/.../force-app/main/default/customMetadata/stateTransition/financing_transitions.externalServiceRegistration-meta.xml'
   

Observation: the CLI attempts to treat force-app/main/default/customMetadata/stateTransition/financing_transitions.yaml as an ExternalServiceRegistration and expects a corresponding *.externalServiceRegistration-meta.xml, even though the file resides under customMetadata and is not an External Service.

Expected result

• *.yml files should only be treated as ExternalServiceRegistration when they are located in the externalServiceRegistrations folder.
• YAML files outside externalServiceRegistrations (for example under customMetadata/...) should not be interpreted as External Services and should not require a *.externalServiceRegistration-meta.xml file.
• sf project deploy start should succeed without ConversionError for YAML files that are only used as inputs for generating Custom Metadata.

Actual result

• After enabling decomposeExternalServiceRegistrationBeta, all *.yml files in the project are inferred as ExternalServiceRegistration.
• Running sf project deploy start fails with:

  Error (ConversionError): Component conversion failed: ENOENT: no such file or directory, open '/Users/adam/IdeaProjects/salesforce/force-app/main/default/customMetadata/stateTransition/financing_transitions.externalServiceRegistration-meta.xml'
  

• In particular, the file
  force-app/main/default/customMetadata/stateTransition/financing_transitions.yaml
  is incorrectly treated as an External Service, even though it is an internal YAML file used for generating Custom Metadata.

Additional information

• The behavior started immediately after running:

  sf project convert source-behavior --behavior decomposeExternalServiceRegistrationBeta --target-org carvago-prod

• The project contains multiple *.yml files in different folders that serve as configuration / generation inputs (for example for Custom Metadata).
  It looks like the detection of External Service YAML files currently relies only on the .yml extension and not on the location (externalServiceRegistrations vs. other folders).

System Information

Shell: zsh (macOS)

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.113.6",
  "nodeVersion": "node-v20.19.4",
  "osVersion": "Darwin 25.1.0",
  "rootPath": "/opt/homebrew/Cellar/sf/2.113.6/libexec/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.39 (core)",
    "@oclif/plugin-commands 4.1.37 (core)",
    "@oclif/plugin-help 6.2.35 (core)",
    "@oclif/plugin-not-found 3.2.72 (core)",
    "@oclif/plugin-plugins 5.4.53 (core)",
    "@oclif/plugin-search 1.2.36 (core)",
    "@oclif/plugin-update 4.7.14 (core)",
    "@oclif/plugin-version 2.2.36 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.52 (core)",
    "@oclif/plugin-which 3.2.42 (core)",
    "@salesforce/cli 2.113.6 (core)",
    "agent 1.24.27 (core)",
    "apex 3.8.7 (core)",
    "api 1.3.3 (core)",
    "auth 3.9.19 (core)",
    "code-analyzer 5.4.0 (user) published 97 days ago (Tue Aug 26 2025) (latest is 5.6.1)",
    "data 4.0.62 (core)",
    "deploy-retrieve 3.23.16 (core)",
    "info 3.4.96 (core)",
    "limits 3.3.71 (core)",
    "marketplace 1.3.8 (core)",
    "org 5.9.45 (core)",
    "packaging 2.23.3 (core)",
    "schema 3.3.88 (core)",
    "settings 2.4.51 (core)",
    "sobject 1.4.79 (core)",
    "telemetry 3.6.66 (core)",
    "templates 56.3.71 (core)",
    "trust 3.7.113 (core)",
    "user 3.6.41 (core)",
    "sfdx-git-delta 6.21.0 (user) published 67 days ago (Fri Sep 26 2025) (latest is 6.23.0)",
    "sfdx-hardis 6.6.0 (user) published 57 days ago (Sun Oct 05 2025) (latest is 6.14.1)"
  ]
}

[github-actions]

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.

[Damecek]

I've managed to avoid the issue by adding this to .forceignore.

# Ignore non-xml files in xml only salesforce folders
force-app/main/default/customMetadata/*
!force-app/main/default/customMetadata/*.md-meta.xml

[WillieRuemmele]

@Damecek - I'm glad you reported this bug, and found a workaround too 🤝

we'll look at making the type inference more strict for externalServiceRegistrations/**/*.yml

[git2gus]

This issue has been linked to a new work item: W-20424423