OpenRouter error telemetry emits inconsistent provider value ("OpenRouter" vs "openrouter")

[edelauna]

Context

PR #1165 canonicalized the OpenRouter ApiProviderError calls to providerIdentifiers.openrouter. See the pending-review note on src/api/providers/openrouter.ts:201.

providerIdentifiers.openrouter is "openrouter" (lowercase). The class field this.providerName is "OpenRouter" (capitalized, openrouter.ts:147). The two values now disagree for the same error event.

Problem

ApiProviderError.provider flows into telemetry through extractApiProviderErrorProperties (packages/types/src/telemetry.ts:475). PR #1165 changed the emitted provider value for OpenRouter errors from "OpenRouter" to "openrouter". This has two effects:

1. Telemetry continuity. A Sentry or PostHog series, query, or alert that groups OpenRouter errors on provider = "OpenRouter" stops matching after deploy. The old series ends and a new "openrouter" series starts.
2. Per-event label divergence. The same catch blocks still call handleOpenAIError(error, this.providerName) at openrouter.ts:368, 379, 638, 649, which keeps "OpenRouter" for the user-facing message. So one error now carries two spellings: "openrouter" in telemetry, "OpenRouter" in the message.

This is the only substitution in PR #1165 that changed a value. All other provider identifiers mapped to strings equal to the literals they replaced.

Fix (fast follow)

Pick one:

1. Keep the lowercase telemetry value. Also change handleOpenAIError(error, this.providerName) to providerIdentifiers.openrouter at the four sites above, so both sinks agree. Update or add an OR clause to any dashboard or alert keyed on the old "OpenRouter" value.
2. Preserve the historical value. Revert the five ApiProviderError provider arguments back to this.providerName.

Either way, add a comment on the providerName field ("display name, not the telemetry identifier"), or an independent test pin on the emitted casing. The current assertions in openrouter.spec.ts reference providerIdentifiers.openrouter on both sides, so they cannot catch a future drift in the emitted value.

References

• PR: refactor(providers): canonicalize model-router calls #1165
• src/api/providers/openrouter.ts:147, 201, 356, 368, 374, 379, 626, 638, 644, 649
• packages/types/src/telemetry.ts:475
• packages/types/src/provider-identifiers.ts:7
• src/api/providers/__tests__/openrouter.spec.ts:354

[nightcityblade]

Hi, I'd like to work on this. I'll submit a PR shortly.

[nightcityblade]

I found the contributor policy also requires confirmed assignment through Discord before opening a PR. I can't complete that step in this run, so I'm stepping back to avoid blocking anyone else.

[Triumph1701]

The telemetry contract should normalize both the display label and the machine identifier at the boundary. I’d emit a stable provider_id (for example, openrouter) and keep provider_name only for UI, then add a regression assertion on the serialized event so dashboards cannot split one provider into two dimensions.