Unlocked package install failing with "null" error for new field.

[jclark-dot-org]

Summary

When attempting to install a new package version with sfdx force:package:install, the install fails with a 'null' error for a new field.

Expected result

This new version adds a new field to a custom MDT, and some code the references it. It should install cleanly; everything works fine in scratch orgs.

Actual result

When installing to a sandbox which has a prior version of the package, we see the following errors:

ERROR:  Encountered errors installing the package!,Installation errors: 
1) (Collections_Base_Setting__mdt.Primary_Secondary_Relationship_Field__c) , Details: Collections_Base_Setting__mdt.Primary_Secondary_Relationship_Field__c: null
2) Dependent class is invalid and needs recompilation:  Class CollectionsUtil : Variable does not exist: Primary_Secondary_Relationship_Field__r, Details: AccountBalanceAPI: Dependent class is invalid and needs recompilation:  Class CollectionsUtil : Variable does not exist: Primary_Secondary_Relationship_Field__r

Error 2 is a direct result of Error 1. Error 1 indicates the new field was not created, but the error message "null" gives no information as to the cause.

Further, if we manually push the new field to the sandbox with force:source:deploy, it succeeds, and then the package install succeeds. We need to understand why the field doesn't work during a package install.

System Information

Observed on mac & linux (Bitbucket Pipelines); here's the version info from my mac:

{
        "cliVersion": "sfdx-cli/7.125.0",
        "architecture": "darwin-x64",
        "nodeVersion": "node-v12.1.0",
        "pluginVersions": [
                "@oclif/plugin-autocomplete 0.3.0 (core)",
                "@oclif/plugin-commands 1.3.0 (core)",
                "@oclif/plugin-help 3.2.3 (core)",
                "@oclif/plugin-not-found 1.2.4 (core)",
                "@oclif/plugin-plugins 1.10.1 (core)",
                "@oclif/plugin-update 1.5.0 (core)",
                "@oclif/plugin-warn-if-update-available 1.7.0 (core)",
                "@oclif/plugin-which 1.0.3 (core)",
                "@salesforce/sfdx-plugin-lwc-test 0.1.7 (core)",
                "alias 1.1.22 (core)",
                "apex 0.3.0 (core)",
                "auth 1.7.3 (core)",
                "config 1.2.41 (core)",
                "custom-metadata 1.0.12 (core)",
                "data 0.6.3 (core)",
                "generator 1.2.0 (core)",
                "limits 1.2.2 (core)",
                "org 1.8.3 (core)",
                "salesforce-alm 53.0.0 (core)",
                "schema 1.0.10 (core)",
                "sfdx-cli 7.123.0 (core)",
                "sfdx-fmz-plugin 1.1.0 (1.1.0)",
                "sfpowerkit 3.3.2",
                "source 1.2.4 (core)",
                "telemetry 1.2.8 (core)",
                "templates 52.4.0 (core)",
                "trust 1.0.8 (core)",
                "user 1.5.2 (core)"
        ],
        "osVersion": "Darwin 18.7.0"
}

The bitbucket pipeline is also using 7.125

Additional information

Feel free to attach a screenshot.

[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.

[maggiben]

Hi, can you run the command with flags --dev-debug and post the logs ? thanks !

[jclark-dot-org]

@maggiben Output of --dev-debug is attached: debug.log Hopefully you'll see something I don't.

Note that I replaced all instances of the package install key and my org user name with placeholder values, but otherwise that is the direct output. Here's the command:

sfdx force:package:install --package 04t6T0000015gIFQAY --wait 10 --securitytype AdminsOnly --noprompt -u dpqa --apexcompile package --installationkey INSTALL_KEY --dev-debug > debug2.log 2>&1

I did notice a JSON Schema validation error in the output which didn't make sense, so I ran my sfdx-project.json through a validator using the schema called out in the log; it seems to be unhappy that I'm not using package aliases, but we've never used them on this project, preferring instead to use the version IDs directly; this has certainly never caused an issue; and obviously it isn't even needed to run the above command. But for completeness, here's the file for reference:

{
    "packageDirectories": [
        {
            "path": "force-app",
            "dependencies": [
                {
                    "package": "04t3y000001qQ8IAAU",
                    "name": "FSL"
                },
                {
                    "package": "04t2E000003e4ILQAY",
                    "name": "Nintex DocGen"
                },
                {
                    "package": "04t2K000000AgLxQAK",
                    "name": "DocuSign eSignature for Salesforce"
                },
                {
                    "package": "04t6T0000015gIFQAY",
                    "name": "collections-app"
                },
                {
                    "package": "04t6T0000015gCqQAI",
                    "name": "fmz-grid"
                }
            ],
            "default": true
        }
    ],
    "namespace": "",
    "sfdcLoginUrl": "https://test.salesforce.com",
    "sourceApiVersion": "51.0"
}

[maggiben]

@jclark-dot-org strange, the schema calls for a package to be a type string a package id would pass the schema, also the schemas haven't been changed in quite some time.
I see this in the logs:

2021-11-15T14:27:59.118Z sfdx:PackageInstallCommand ERROR [
  'ERROR running force:package:install: ',
  'Installation errors: \n' +
    '1) (Collections_Base_Setting__mdt.Primary_Secondary_Relationship_Field__c) , Details: Collections_Base_Setting__mdt.Primary_Secondary_Relationship_Field__c: null\n' +
    '2) Dependent class is invalid and needs recompilation:  Class CollectionsUtil : Variable does not exist: Primary_Secondary_Relationship_Field__r, Details: AccountBalanceAPI: Dependent class is invalid and needs recompilation:  Class CollectionsUtil : Variable does not exist: Primary_Secondary_Relationship_Field__r',
  '\n' +
    '*** Internal Diagnostic ***\n' +
    '\n' +
    'Error: Installation errors: \n' +
    '1) (Collections_Base_Setting__mdt.Primary_Secondary_Relationship_Field__c) , Details: Collections_Base_Setting__mdt.Primary_Secondary_Relationship_Field__c: null\n' +
    '2) Dependent class is invalid and needs recompilation:  Class CollectionsUtil : Variable does not exist: Primary_Secondary_Relationship_Field__r, Details: AccountBalanceAPI: Dependent class is invalid and needs recompilation:  Class CollectionsUtil : Variable does not exist: Primary_Secondary_Relationship_Field__r\n' +
    '    at /Users/jclark/.local/share/sfdx/client/7.123.0-ebc9b0f/node_modules/salesforce-alm/dist/lib/package/packageInstallCommand.js:94:27\n' +
    '    at processTicksAndRejections (internal/process/task_queues.js:95:5)\n' +
    'From previous event:\n' +
    '    at listOnTimeout (internal/timers.js:557:17)\n' +
    '    at processTimers (internal/timers.js:500:7)\n' +
    'From previous event:\n' +
    '    at /Users/jclark/.local/share/sfdx/client/7.123.0-ebc9b0f/node_modules/salesforce-alm/dist/lib/package/packageInstallCommand.js:100:73\n' +
    '    at processTicksAndRejections (internal/process/task_queues.js:95:5)\n' +
    'Outer stack:\n' +
    '    at Function.wrap (/Users/jclark/.local/share/sfdx/client/7.123.0-ebc9b0f/node_modules/salesforce-alm/node_modules/@salesforce/core/lib/sfdxError.js:171:27)\n' +
    '    at PackageInstallCommand.catch (/Users/jclark/.local/share/sfdx/client/7.123.0-ebc9b0f/node_modules/salesforce-alm/dist/ToolbeltCommand.js:253:46)\n' +
    '    at async PackageInstallCommand._run (/Users/jclark/.local/share/sfdx/client/7.123.0-ebc9b0f/node_modules/@salesforce/command/lib/sfdxCommand.js:85:13)\n' +
    '    at async Config.runCommand (/Users/jclark/.local/share/sfdx/client/7.123.0-ebc9b0f/node_modules/@oclif/config/lib/config.js:173:24)\n' +
    '    at async SfdxMain.run (/Users/jclark/.local/share/sfdx/client/7.123.0-ebc9b0f/node_modules/@oclif/command/lib/main.js:27:9)\n' +
    '    at async SfdxMain._run (/Users/jclark/.local/share/sfdx/client/7.123.0-ebc9b0f/node_modules/@oclif/command/lib/command.js:43:20)\n' +
    '    at async Object.run (/Users/jclark/.local/share/sfdx/client/7.123.0-ebc9b0f/dist/cli.js:162:47)\n' +
    '******\n'
]

Have you seen this error before ?
Also have you by any chance updated the CLI ? if so, can you try downgrading ?

[jclark-dot-org]

@maggiben Yes, those two errors are the same 2 errors from my original post. Error 1 is the failed field deploy, with "null" as the reason, and Error 2 is just an apex class failing to compile because the field is missing. I cannot figure out why Error 1 is occurring, as there is no error message. If I manually force:source:deploy that field it will succeed, and then package installation can proceed.

edit to add: This was using CLI 7.123, but we also tried it with 7.125 and 7.92, with identical results.

[github-actions]

We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.

[shetzel]

Hoping to get some packaging specialist eyes on this...

[shetzel]

@jclark-dot-org - Sorry this has remained open for so long without a resolution. We are trying to clean up old issues like this one. I was able to get this in front of the packaging team and they think this is a problem for the owner of the metadata type (CustomMetadata in this case). Many times errors with packaging operations are actually a problem with the metadata type implementation itself and this appears to be the case with this issue. If you are still hitting this issue or would like a resolution then please open a support case.

One last thing to ensure is if the package version that was created contains the expected contents. You can inspect the package contents sent in the request to create the package version by using the --preserve flag, then opening the directory and verifying it all looks correct. If it does, then this is 100% a problem for the owners of that metadata type.