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

Offen
#3,686 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
javascript, node.js
Bereich
backend, cli

Rechercherichtung

Start by comparing the packaging and source-deploy-retrieve versions bundled in CLI 2.157.7 and 2.157.8, then trace how package version creation processes custom label translations. The issue reports that removing the <customLabels> entries makes creation succeed, while a single entry reproduces the failure. Confirm the cause and verify that package B's version can be created with its translated labels.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

investigating regression validated
Before You Submit
  • I'm using the latest version of Salesforce CLI
  • I've searched the existing issues
  • I've run sf doctor to 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
  1. Two 2GP managed packages share one namespace: package A, and package B, which depends on A.
  2. Package B contains labels/CustomLabels.labels-meta.xml (about 200 labels) and translations/de.translation-meta.xml with <customLabels> entries that translate B's own labels. Package A has its own labels and its own de translation file.
  3. 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-packaging is 3.0.17 in both 2.157.x versions, but a fresh npx @salesforce/cli@<v> install bundles @salesforce/packaging 5.0.27 / source-deploy-retrieve 13.12.0 in 2.157.7, and 5.0.26 / 13.11.0 in 2.157.8.
  • Dropping the <customLabels> entries from B's de.translation-meta.xml makes 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

Vorherrschende Sprache
Keine Sprachdaten
Sterne
575
Forks
80
Ø Merge
5 Std. 58 Min.
Gemergte PRs (30 T.)
4

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus forcedotcom/cli

Alle Issues in forcedotcom/cli

Ähnliche Issues

Weitere Issues zu Backend & API Design

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.