Filed unassigned by the domain:cli execution PM seat (#6024), session session_01UngCYXF98BVpYA9hfz6NYk, while closing #13463 against the merged tree. Recording only — not claimed.
The finding
#13463 said serve.ts's cluster-driver load swallowed the objectstackHostImportFailureKind classification with an empty catch, so a missing package.json declaration surfaced later as a registry problem naming the wrong remedy. PR #14042 repaired that site: the error is captured, hostImportFailureKind is read, and the gate's own remedy text is printed.
The same shape survives one site over. Measured on merged main (packages/cli/src/commands/serve.ts:2851, the i18n service load):
const{ I18nServicePlugin }=awaitimportFromHost(i18nPkg);…}catch{A bare catch {} — the classification createHostImporter produced is discarded, exactly as #13463 described for the cluster driver.
Census of the class, so the population is stated rather than implied
All six importFromHost call sites in serve.ts on merged main:
| site | handling |
|---|
:1157 plugin import | catch (importError) → throws carrying the message |
:2442 cluster module | reading (repaired by #14042) |
:2515 cluster driver | reading (repaired by #14042 — #13463) |
:2851 i18n | ⛔ bare catch {} — this card |
:3462 organizations | catch (orgErr), handled with a stated reason |
:3838 generic loader | detail-carrying throw / console.warn |
⇒ One of six.⚠️ That count is a reading of serve.ts only; it is not a claim about importFromHost consumers elsewhere. The other in-repo consumers of the declared leg are packages/verify/src/harness.ts:515 and packages/qa/dogfood/test/enterprise-organizations.ts:107 — neither was examined for this class, and whoever takes this card should say whether they looked rather than leaving it ambiguous.
Why p3 rather than p2
⚠️ Graded below#13463 deliberately, and the reason is the consequence, not the shape.
#13463's cluster-driver swallow was p2 because the misleading message landed on the licensed multi-node boot path, where the operator is mid-deployment and the wrong remedy costs a real investigation. The i18n load is optional by design — its catch exists because a missing i18n package is a supported configuration, not a failure. So the swallow here mostly hides "you did not install the optional thing you did not ask for", which is close to harmless.
⇒ It is worth fixing for consistency and for the case where the package is declared and fails for another reason (a broken dependency reporting as "absent"), which is the same trap #14042 named at the cluster site: "a driver with a broken dependency reported as 'not registered', sending operators to look for a package already installed."
Suggested shape — and one thing to check first
Mirror what #14042 did at :2515: capture the error, read hostImportFailureKind, and warn with the gate's own text when the kind is known; keep a distinct message for resolved-then-crashed. ⛔ Do not re-throw — the tolerance is the point of the catch, and #14042's stated rule is that every branch is a diagnosis printed ahead of unchanged behaviour.
⚠️Check before implementing: confirm the i18n path is genuinely optional-by-design on the current tree. If it is actually required in some configuration, this is a different and larger card than the one filed here, and it should be re-graded rather than implemented as written.
Refs
Filed unassigned by the
domain:cliexecution PM seat (#6024), sessionsession_01UngCYXF98BVpYA9hfz6NYk, while closing #13463 against the merged tree. Recording only — not claimed.The finding
#13463 said
serve.ts's cluster-driver load swallowed theobjectstackHostImportFailureKindclassification with an empty catch, so a missingpackage.jsondeclaration surfaced later as a registry problem naming the wrong remedy. PR #14042 repaired that site: the error is captured,hostImportFailureKindis read, and the gate's own remedy text is printed.The same shape survives one site over. Measured on merged
main(packages/cli/src/commands/serve.ts:2851, the i18n service load):A bare
catch {}— the classificationcreateHostImporterproduced is discarded, exactly as #13463 described for the cluster driver.Census of the class, so the population is stated rather than implied
All six
importFromHostcall sites inserve.tson mergedmain::1157plugin importcatch (importError)→ throws carrying the message:2442cluster module:2515cluster driver:2851i18ncatch {}— this card:3462organizationscatch (orgErr), handled with a stated reason:3838generic loaderthrow/console.warn⇒ One of six.⚠️ That count is a reading of
serve.tsonly; it is not a claim aboutimportFromHostconsumers elsewhere. The other in-repo consumers of the declared leg arepackages/verify/src/harness.ts:515andpackages/qa/dogfood/test/enterprise-organizations.ts:107— neither was examined for this class, and whoever takes this card should say whether they looked rather than leaving it ambiguous.Why p3 rather than p2
#13463's cluster-driver swallow was p2 because the misleading message landed on the licensed multi-node boot path, where the operator is mid-deployment and the wrong remedy costs a real investigation. The i18n load is optional by design — its catch exists because a missing i18n package is a supported configuration, not a failure. So the swallow here mostly hides "you did not install the optional thing you did not ask for", which is close to harmless.
⇒ It is worth fixing for consistency and for the case where the package is declared and fails for another reason (a broken dependency reporting as "absent"), which is the same trap #14042 named at the cluster site: "a driver with a broken dependency reported as 'not registered', sending operators to look for a package already installed."
Suggested shape — and one thing to check first
Mirror what #14042 did at
:2515: capture the error, readhostImportFailureKind, and warn with the gate's own text when the kind is known; keep a distinct message for resolved-then-crashed. ⛔ Do not re-throw — the tolerance is the point of the catch, and #14042's stated rule is that every branch is a diagnosis printed ahead of unchanged behaviour.Refs
importcondition, and read the cluster registry instead of assuming it #14042) — the same class at the cluster-driver load, with the measurement that motivated the repairimportcondition, and read the cluster registry instead of assuming it #14042 — the repair whose shape this card asks to mirror