fix(telemetry): use {feature}_{name} composite key as internal metric identifier

[spbolton]

Summary

• Reverts TotalContentsDatabaseMetricType.getName() from "COUNT_CONTENT" back to "COUNT" — restores contentlets_count in downstream telemetry reporting
• Adds MetricType.getQualifiedName() returning {FEATURE}_{NAME} for internal uniqueness (caching, map keys, i18n)
• Removes the getMappedMetricName() disambiguation hack in UsageResource
• Updates all i18n keys to use qualified names (e.g., CONTENTLETS_COUNT, LANGUAGES_COUNT)

Context

PR #34479 renamed the contentlets metric from "COUNT" to "COUNT_CONTENT" to resolve a naming collision with the languages metric. This broke the downstream telemetry reporting layer — the metrics_table_view in the telemetry database derives keys as lower(feature) || '_' || lower(name) and maps them into a hardcoded metric_stat PostgreSQL composite type. The rename changed the derived key from contentlets_count to contentlets_count_content, which has no matching column and is silently dropped by json_populate_record.

Production impact: contentlets_count has been NULL for 145 of 153 cloud clients since ~Jan 7, 2026 (~10 weeks of missing data). This blocks team bonus metrics and customer health reporting.

The fix introduces getQualifiedName() as the internal unique identifier while keeping the wire format unchanged, so the external reporting layer continues to work without modification.

Changes

File	Change
MetricType.java	Add default getQualifiedName() returning FEATURE_NAME
TotalContentsDatabaseMetricType.java	Revert getName() from "COUNT_CONTENT" → "COUNT"
MetricStatsCollector.java	Use getQualifiedName() for cache key, name filter, logging, timing
UsageResource.java	Remove getMappedMetricName() hack; use qualified names for map keys
DashboardMetricsProvider.java	getDashboardMetricByName() matches on qualified name
Language*.properties (9 files)	Update i18n keys to qualified name format
UsageResourceIntegrationTest.java	Update assertions for qualified name keys

Test plan

• Verify contentlets_count column is populated in metrics_table_view after deployment
• Verify Usage Dashboard displays all metrics correctly with new qualified name i18n keys
• Run UsageResourceIntegrationTest — all assertions updated for qualified names
• Verify external telemetry payload sends "name": "COUNT" with "feature": "CONTENTLETS"

Fixes #35010
Closes #34042
Fixes #35002

🤖 Generated with Claude Code

[claude]

Claude finished @spbolton's task in 2m 5s —— View job

---

Rollback Safety Re-Analysis (PR Synchronize)

• Read rollback-unsafe categories reference
• Get full PR diff
• Analyze diff against all categories
• Post result

---

Findings

No new rollback-unsafe categories introduced by the new commits. The existing M-3 finding from the prior analysis remains the only applicable category.

---

Category: M-3 — REST API Contract Change
Risk Level: 🟡 MEDIUM

Why it's unsafe: The /api/v1/usage response changes the name field value for every metric in the dashboard. All 17 metric keys are renamed from NAME-only format to FEATURE_NAME qualified format:

Old name	New name
COUNT_CONTENT	CONTENTLETS_COUNT
COUNT_LANGUAGES	LANGUAGES_COUNT
COUNT_OF_SITES	SITES_COUNT_OF_SITES
COUNT_OF_USERS	USERS_COUNT_OF_USERS
… (13 more)	…

If N is deployed and then rolled back to N-1, the API reverts to the old name values. Any browser that cached N's Angular bundle (which reads name dynamically and uses it as an i18n key) would request usage.metric.CONTENTLETS_COUNT.label from N-1's backend, which only has usage.metric.COUNT_CONTENT.label — resulting in raw key strings shown to the user until the cache expires.

Code that makes it unsafe:

• UsageResource.java line ~192: metricData.put("name", qualifiedName) — qualifiedName is now CONTENTLETS_COUNT, previously COUNT_CONTENT
• Language.properties lines 6408–6424: all 17 i18n keys renamed from usage.metric.COUNT_CONTENT.label → usage.metric.CONTENTLETS_COUNT.label (and equivalent for all other metrics)

Mitigating factors acknowledged:

• The Angular frontend is updated in the same PR (dot-usage.service.ts, component specs) — so both sides are consistent at deployment time
• The UI reads name dynamically and does not hardcode individual metric names — so no hard wiring breaks
• This endpoint is only consumed by the internal Usage Dashboard, not a public headless API

The rollback risk is limited to the browser-cache window where a client holds N's JS bundle against N-1's API. Normal cache expiry resolves it without ops intervention. Despite these mitigations, the API contract change still matches M-3 per the reference document.

Alternative: Maintain both old and new keys in Language.properties for one release (the old keys could map to the same translated strings), so that a brief rollback window doesn't degrade the UI. This is low-effort and eliminates the cache-window risk entirely.

---

All other categories were checked and are clear:

• C-1/C-2/C-3/C-4: No database migrations, no runonce tasks, no ES mapping changes, no DROP/RENAME operations
• H-1 through H-7: No data transformations, no PK changes, no storage provider changes
• M-1: No column type changes
• M-2: No push publishing bundle format changes
• M-4: No OSGi public interface changes

[claude]

Pull Request Unsafe to Rollback!!!

• Category: M-3 — REST API Contract Change
• Risk Level: 🟡 MEDIUM
• Why it's unsafe: The /api/v1/usage response changes the name field values for all usage dashboard metrics (e.g., COUNT_CONTENT → CONTENTLETS_COUNT, COUNT_LANGUAGES → LANGUAGES_COUNT), and the displayLabel i18n keys change format from usage.metric.COUNT_CONTENT.label to usage.metric.CONTENTLETS_COUNT.label. If N is deployed and then rolled back to N-1, the API reverts to returning the old name values. Any frontend or integration that adapted to N's new key format would break during the rollback window.
• Code that makes it unsafe: dotCMS/src/main/java/com/dotcms/rest/api/v1/usage/UsageResource.java lines ~192 and ~247: metricData.put("name", qualifiedName) where qualifiedName is e.g. CONTENTLETS_COUNT — previously this was COUNT_CONTENT. Also dotCMS/src/main/webapp/WEB-INF/messages/Language.properties: all 18 i18n metric keys renamed (e.g. usage.metric.COUNT_CONTENT.label → usage.metric.CONTENTLETS_COUNT.label). No corresponding Angular frontend changes appear in this PR.
• Alternative (if possible): Maintain backward compatibility by returning both the old name and the new qualifiedName as separate fields in the response for one release, then drop the old name in the following release. This allows the frontend and any consumers to migrate without a hard cut-over.

[spbolton]

Pull Request Unsafe to Rollback!!!

• Category: M-3 — REST API Contract Change
• Risk Level: 🟡 MEDIUM
• Why it's unsafe: The /api/v1/usage response changes the name field values for all usage dashboard metrics (e.g., COUNT_CONTENT → CONTENTLETS_COUNT, COUNT_LANGUAGES → LANGUAGES_COUNT), and the displayLabel i18n keys change format from usage.metric.COUNT_CONTENT.label to usage.metric.CONTENTLETS_COUNT.label. If N is deployed and then rolled back to N-1, the API reverts to returning the old name values. Any frontend or integration that adapted to N's new key format would break during the rollback window.
• Code that makes it unsafe: dotCMS/src/main/java/com/dotcms/rest/api/v1/usage/UsageResource.java lines ~192 and ~247: metricData.put("name", qualifiedName) where qualifiedName is e.g. CONTENTLETS_COUNT — previously this was COUNT_CONTENT. Also dotCMS/src/main/webapp/WEB-INF/messages/Language.properties: all 18 i18n metric keys renamed (e.g. usage.metric.COUNT_CONTENT.label → usage.metric.CONTENTLETS_COUNT.label). No corresponding Angular frontend changes appear in this PR.
• Alternative (if possible): Maintain backward compatibility by returning both the old name and the new qualifiedName as separate fields in the response for one release, then drop the old name in the following release. This allows the frontend and any consumers to migrate without a hard cut-over.

It is great that this was found, but I don't think in this case we need to worry about the backwards compatibility as long as the frontend is internally consistent. It is only the usage dashboard currently tied to this api. Note that other than the tests, the actual names/labels are read by the ui and used as is, so it is not actually referencing individual metrics at all, UI currently will handle the name change invisibly.

[yolabingo]

I don't know what a "bean" is but, beyond that, LGTM