Case Insensitive Filesystem Breaks Metadata Subscription

Issue #1813 resolved
Xander Victory created an issue

In an SFDX project, with the subscription mode defaulted to the greyed out ‘All’ option, I had weird behaviour when a filename had a capital where the org/class-name had a lowercase. (probably old copy of the file)

  • Deploy/retrieve refused to show it as subscribed (when module config said it was)
  • Compare With Server retrieved metadata, but then did nothing but display a ‘Retrieve successful’ message

Comments (3)

  1. Scott Wells repo owner

    I just committed a few fixes for this issue:

    1. Ensure that when there's a case-only mismatch between server and local, the metadata object is properly included in the build options dialog used for bulk deployment, retrieval, and removal.
    2. On deployment of a metadata object with a case-only mismatch, the local name is used in the resulting package.xml which ensures that the server name's case is updated to reflect the local name.
    3. On retrieval of a metadata object with a case-only mismatch, the server name is used in the resulting package.xml since evidently matching against the retrieval manifest occurs in a case-sensitive manner.

    This will all be included in the next build.

  2. Scott Wells repo owner

    By the way, this issue exists not just for a case-insensitive file system. Even on a case-sensitive filesystem you could reproduce the issue as follows:

    1. Create a class named Issue1813 contained in local files Issue1813.cls and Issue1813.cls-meta.xml.
    2. Deploy that class successfully to Salesforce.
    3. Rename the local files to issue1813.cls and issue1813.cls-meta.xml and update the class name itself to issue1813.
    4. Try to deploy the class via the metadata API or retrieve it and it will fail without the fixes mentioned above. Note that deployment via the tooling API will work because it deploys by ID. That deployment will result in the ApexClass object's name being updated to issue1813.

    With these fixes all of this will work, and deployment via the metadata API will now behave like deployment via the tooling API where the case of the server version's name will be updated to reflect the case of the local version's name. with case-insensitivity...the gift that keeps on giving.

  3. Log in to comment