Repository navigation
[BUG]: package version create fails with "External string does not exist" for a dependent package's own labels when it ships label translations (2.157.7 works, 2.157.8 fails) #3686
Description
Before You Submit
- I'm using the latest version of Salesforce CLI
- I've searched the existing issues
- I've run
sf doctorto diagnose common issues
Related Issue
No response
Command
sf package version create --package --installation-key-bypass --skip-ancestor-check --code-coverage --wait 120 --json
Org Type
Production
Did this work before?
Yes, this is a regression
Last Working Version
2.157.7.
Summary
sf package version create fails for a 2GP managed package that depends on another package in the same namespace and ships translations of its own custom labels. Every Apex class that uses one of the package's own labels fails with External string does not exist. The same source builds with 2.157.7 and fails with 2.157.8, the version salesforce/cli:latest-full has pointed to since 2026-11-04.
Repository to Reproduce
No response
Steps to reproduce
- Two 2GP managed packages share one namespace: package A, and package B, which depends on A.
- Package B contains
labels/CustomLabels.labels-meta.xml(about 200 labels) andtranslations/de.translation-meta.xmlwith<customLabels>entries that translate B's own labels. Package A has its own labels and its owndetranslation file. - Run
sf package version create --package B --installation-key-bypass --skip-ancestor-check --wait 120.
Expected Result
The version is created, as it is with 2.157.7.
Actual Result
With 2.157.8:
Class X: External string does not exist: <a label of package B>
Class Y: Dependent class is invalid and needs recompilation: ... External string does not exist: <label>
All of package B's labels are reported missing, including one that has no German translation.
Error Message
ERROR running package version create: MultipleErrorsError
Multiple errors occurred:
(1) Class TA_Marketing360Setting_Validation: Dependent class is invalid and needs recompilation:
Class AUTO360.Marketing360SettingValidation : External string does not exist: ErrorMarketing360SettingInvalidMidBu
(2) Class MCDataExtensionProvisioner: Dependent class is invalid and needs recompilation:
Class MCDataExtensionProvisioner : External string does not exist: ErrorMarketing360SettingInvalidMidBu
(3) Class TA_Marketing360Settings_ValidationTest: External string does not exist: Marketing360Setting_ParamName_MaxStockItemsEmail
... (about 200 more errors of the same kind, one per class that uses one of the package's own labels)System Information
{
"architecture": "darwin-arm64",
"cliVersion": "@salesforce/cli/2.157.8",
"nodeVersion": "node-v24.22.1",
"osVersion": "Darwin 27.0.0",
"rootPath": "<npx cache>/node_modules/@salesforce/cli",
"shell": "zsh",
"pluginVersions": [
"@oclif/plugin-autocomplete 4.0.6 (core)",
"@oclif/plugin-commands 5.0.6 (core)",
"@oclif/plugin-help 7.0.6 (core)",
"@oclif/plugin-not-found 4.0.7 (core)",
"@oclif/plugin-plugins 7.0.13 (core)",
"@oclif/plugin-search 2.0.9 (core)",
"@oclif/plugin-update 5.0.10 (core)",
"@oclif/plugin-version 3.0.7 (core)",
"@oclif/plugin-warn-if-update-available 4.0.5 (core)",
"@oclif/plugin-which 4.0.6 (core)",
"@salesforce/cli 2.157.8 (core)",
"agent 2.2.3 (core)",
"apex 4.4.4 (core)",
"api 2.0.24 (core)",
"auth 6.0.0 (core)",
"code-analyzer 5.16.0 (user) published 76 days ago (Wed Aug 26 2026)",
"data 5.1.24 (core)",
"deploy-retrieve 4.3.2 (core)",
"info 4.0.22 (core)",
"limits 4.0.6 (core)",
"marketplace 2.0.23 (core)",
"org 7.0.10 (core)",
"packaging 3.0.17 (core)",
"schema 4.0.16 (core)",
"settings 3.0.22 (core)",
"sobject 2.0.20 (core)",
"telemetry 4.2.4 (core)",
"templates 57.5.0 (core)",
"trust 4.0.28 (core)",
"user 6.0.6 (core)",
"sfdmu 5.6.4 (user) published 207 days ago (Fri Apr 17 2026) (latest is 5.8.0)"
]
}Additional Information
- 2.157.7 builds it. 2.157.8 and 2.154.4 fail.
plugin-packagingis 3.0.17 in both 2.157.x versions, but a freshnpx @salesforce/cli@<v>install bundles@salesforce/packaging5.0.27 /source-deploy-retrieve13.12.0 in 2.157.7, and 5.0.26 / 13.11.0 in 2.157.8. - Dropping the
<customLabels>entries from B'sde.translation-meta.xmlmakes 2.154.4 build it too. Keeping a single entry is enough to fail. - The core version B depends on and B's ancestor make no difference.
- Packages in the same project without translation files build fine with 2.157.8.
Screenshots or Log Files
No response
Activity
github-actions commentedon Nov 10, 2026
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.
git2gus commentedon Nov 10, 2026
This issue has been linked to a new work item: W-24856210
k80bowman commentedon Nov 10, 2026
Thanks so much for the detailed report. We compared the two releases and haven't found a CLI-side change that explains this yet, so we'd like a few more details.
Could you please run
sf package version createwith the--generatepkgzipflag on a failing run (2.157.8) and a passing run (2.157.7), and diff the resulting package.zip files? In particular we are curious aboutlabels/CustomLabels.labelsandtranslations/de.translation. I'd also be interested in knowing if the 2.157.8/fails, 2.157.7/succeeds pattern is consistent, just to rule out any flakiness.cklepik commentedon Nov 12, 2026
Thanks for looking into it. Short answer: the pattern is not consistent, so this is flaky rather than a 2.157.7 -> 2.157.8 regression.
Consistency. Six more runs today (12 Nov, ~12:24 UTC), same Dev Hub, same marketing360 sources. They were built from two checkouts that differ in the version of the core package this package depends on, and in other packages' sources, but have identical marketing360 contents:
Since 9 Nov for this package: 2.157.7 passed 3 of 6, 2.157.8 passed 1 of 7. Every failure is the same error for the same 16 labels.
Uploaded package.zip, failing runs.
--generate-pkg-zipdoes not write a file locally, so I kept the uploaded package.zip with--preservefor four runs (2 x 2.157.7, 2 x 2.157.8, all four failed):labels/CustomLabels.labels(md5 fdfb6be0bca09c78c43f13830ed8fd5e, 204 labels) andtranslations/de.translation(md5 4e03c43695430eae9437f468c0501210, 195 customLabels).scratch-org-definition.jsonand the contents ofsettings.zipare identical too;package2-descriptor.jsonis identical apart fromversionName/versionNumber.labels/beforeclasses/and afterclasses/both failed, and so did two earlier runs with the order forced to alphabetical.Passing run. I downloaded DeveloperUsePkgZip for the one success (08cSl0000005LYTIA2, built with 2.157.8) and compared it with the failing uploads. It is the server's re-export, so not byte-comparable, but semantically I find no difference:
labels/CustomLabels.labels: the same 204 labels with identical fields, only sorted;translations/de.translation: the same 195 customLabels with identical text, plus 9 empty entries for the labels that have no translation and an empty flowDefinitions entry;<packageVersions>/<deprecated>elements).Since the same payload passes or fails between attempts, this looks server-side to me. If you agree, could you loop in the team that owns package version creation on the server side? Feel free to retitle the issue.