fix(observability): demote OpenHuman backend unknown-model 400 (TAURI-RUST-2Z1)#2464
fix(observability): demote OpenHuman backend unknown-model 400 (TAURI-RUST-2Z1)#2464CodeGhost21 wants to merge 2 commits into
Conversation
…-RUST-2Z1) The OpenHuman hosted backend now emits the OpenAI-compatible "Model 'X' is not available. Use GET /openai/v1/models …" wire body for user-configured unknown model ids — a body shape the polarity guard in `is_provider_config_rejection_http` had previously assumed only third-party `custom_openai` upstreams would speak. Result: the per-attempt event reached Sentry as a real error (TAURI-RUST-2Z1) even though the underlying condition is pure user-state (the user typed an unknown model id and configured `model_fallbacks` with `custom:`-prefixed variants that the backend also rejected). Drop the polarity guard for that one body shape via a new narrow helper `is_openai_compatible_unknown_model_message` anchored on the `/openai/v1/models` remediation hint. Other config-rejection phrases (DeepSeek `supported api model names are`, Moonshot `invalid temperature`, litellm envelopes, OpenRouter `requires more credits`) stay polarity-gated so a regression where our own backend started emitting them would still reach Sentry. The aggregate sibling TAURI-RUST-2Z2 is already auto-demoted by the message-only classifier in `core::observability::expected_error_kind` (via tinyhumansai#2239's `/openai/v1/models` phrase).
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThis PR adds a new classifier for OpenAI-compatible "unknown model" error messages and integrates it into the HTTP rejection suppression logic. The classifier detects the specific wire shape via the ChangesUnknown Model Suppression
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
…known-model-polarity
Summary
The OpenHuman hosted backend now emits the OpenAI-compatible
Model 'X' is not available. Use GET /openai/v1/models …wire body for user-configured unknown model ids. The HTTP-layer wrapperis_provider_config_rejection_httpinsrc/openhuman/inference/provider/ops.rswas polarity-gated onprovider != openhuman_backend::PROVIDER_LABELfor all config-rejection phrases — built on the older assumption that only third-partycustom_openaiupstreams would speak this dialect. So the per-attempt event from a user-typed unknown model id reached Sentry as a real error (TAURI-RUST-2Z1) even though the underlying condition is pure user-state.This PR drops the polarity guard for that one specific shape via a narrow new helper
is_openai_compatible_unknown_model_message, anchored on the stable/openai/v1/modelsremediation-hint substring. Every other config-rejection phrase (DeepSeeksupported api model names are, Moonshotinvalid temperature: only 1 is allowed, litellm envelopes, OpenRouterrequires more credits) stays polarity-gated so a regression where our own backend started emitting one of those would still reach Sentry.The aggregate sibling TAURI-RUST-2Z2 is already auto-demoted by the message-only classifier in
core::observability::expected_error_kind(via #2239's/openai/v1/modelsphrase). This PR addresses the missing per-attempt half.What changed
src/openhuman/inference/provider/config_rejection.rsis_openai_compatible_unknown_model_message(body)— strict subset of the broader phrase matcher, pinned to/openai/v1/models.src/openhuman/inference/provider/ops.rsis_provider_config_rejection_httpnow bypasses theopenhuman_backendpolarity guard only whenis_openai_compatible_unknown_model_messagematches; all other config-rejection phrases retain the guard.src/openhuman/inference/provider/mod.rsis_openai_compatible_unknown_model_messagefor cross-module access.Test plan
cargo test --lib openhuman::inference::provider::config_rejection— 6 passed, including two new tests:unknown_model_helper_matches_openai_compatible_bodies(pins the exact TAURI-RUST-2Z1 wire body) andunknown_model_helper_rejects_other_config_rejection_phrases(guards the narrow-scope invariant).cargo test --lib openhuman::inference::provider::ops::tests::provider_config_rejection_suppression— 7 passed, including a new testopenhuman_backend_openai_compatible_unknown_model_is_suppressedplus an additional assertion in the existingopenhuman_backend_same_body_is_not_suppressedtest confirming TIER_LEAK_BODY and TEMP_BODY both still bypass demotion for the backend.cargo test --lib openhuman::inference::provider— 272 passed, 0 failed.cargo test --lib core::observability— 81 passed, 0 failed (no regression in the message-only classifier path).cargo fmtclean,cargo check --libclean (only pre-existing unrelated warnings).Polarity rationale
The narrow helper is the polarity-safe minimum: only the OpenAI-compatible "unknown model" body shape is now treated as user-state regardless of provider. The hosted backend has deliberately adopted that wire shape to mirror the OpenAI
/v1/modelscontract, and the same body carries the same user-state semantics whether the upstream iscustom_openai, DeepSeek, OpenRouter, or our own backend. Other phrases that the backend does not emit stay actionable.If the backend ever starts emitting one of the polarity-gated phrases in error, the existing
openhuman_backend_same_body_is_not_suppressedregression test will keep firing the Sentry event so we'd see it.Summary by CodeRabbit
Bug Fixes
Tests