Project Retrieve does not respect ignored files for multiple package directories projects

[petter-eikeland]

Summary

If ignoring a file placed in a non-default package directory, sfdx project retrieve does not respect the ignore. This is a problem for projects that provision scratch orgs with preinstalled metadata as duplicate files are created when retrieving metadata.

Steps To Reproduce:

Repository to reproduce: dreamhouse-lwc

1. Create a new non-default package directory ignored-retrieve-bug and list another directory default as default ("default": true) in sfdx-project.json
2. Add a file to the local ignored-retrieve-bug directory, e.g. a LoggerAdmin permissions set
3. Ignore the file in .forceignore using *LoggerAdmin.permissionset-meta.xml
4. Create an empty scratch org
5. Create a new permission set in the scratch org with the same API name: LoggerAdmin
6. Run sfdx project retrieve preview and verify that the file is ignored
7. Run sfdx project retrieve start

Expected result

No changes or new files are retrieved

Actual result

A duplicate LoggerAdmin permission set is retrieved into the default directory

System Information

{
  "cliVersion": "sfdx-cli/7.200.6",
  "architecture": "darwin-arm64",
  "nodeVersion": "node-v18.16.0",
  "osVersion": "Darwin 22.4.0",
  "shell": "zsh",
  "rootPath": "/Users/user/.local/share/sfdx/client/7.200.6-d8413f2",
  "pluginVersions": [
    "@dxatscale/sfpowerscripts 20.30.5 (user)",
    "@eon-com/eon-sfdx 1.13.3 (user)",
    "@oclif/plugin-autocomplete 2.1.9 (core)",
    "@oclif/plugin-commands 2.2.14 (core)",
    "@oclif/plugin-help 5.2.9 (core)",
    "@oclif/plugin-not-found 2.3.23 (core)",
    "@oclif/plugin-plugins 3.0.1 (core)",
    "@oclif/plugin-search 0.0.17 (core)",
    "@oclif/plugin-update 3.1.13 (core)",
    "@oclif/plugin-version 1.3.3 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.36 (core)",
    "@oclif/plugin-which 2.2.19 (core)",
    "1commerce 0.0.10 (user)",
    "apex 2.2.15 (core)",
    "auth 2.7.14 (core)",
    "community 2.2.11 (core)",
    "custom-metadata 2.1.19 (core)",
    "data 2.3.14 (core)",
    "deploy-retrieve 1.8.18 (core)",
    "info 2.6.10 (core)",
    "limits 2.3.13 (core)",
    "org 2.8.1 (core)",
    "packaging 1.16.11 (core)",
    "schema 2.3.10 (core)",
    "settings 1.4.6 (core)",
    "signups 1.4.14 (core)",
    "source 2.10.7 (core)",
    "telemetry 2.2.0 (core)",
    "templates 55.4.13 (core)",
    "trust 2.4.14 (core)",
    "user 2.3.10 (core)",
    "@salesforce/sfdx-diff 0.0.6 (user)",
    "@salesforce/source-tracking 3.1.1 (user)",
    "sfdmu 4.26.13 (user)",
    "sfdx-cli 7.200.6 (core)",
    "sfpowerkit 6.1.0 (user)"
  ]
}

Additional information

[petter-eikeland]

This bug also existed with sfdx force source pull, so it has not been introduced with sfdx project retrieve

[iowillhoit]

Hey @petter-eikeland, thank you for the excellent repro. I am seeing the same. Curious, are you seeing the same behavior with any other metadata types or just permissionsets? I just tried something similar with a CustomObject and it seems like it was properly ignored.

[git2gus]

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

[petter-eikeland]

Hi @iowillhoit, thanks!

Good question. Not sure, however after speaking with my devs they say they often get customObjectTranslations, fieldRestrictionRules & customindex Metadata Types even though we have ignored them (no idea how they retrieve the last 2 😅)

[iowillhoit]

Ok, good to know! Thanks again and we'll look into this