fix(observability): classify backend 4xx as BackendUserError (OPENHUMAN-TAURI-BC)

[CodeGhost21]

Summary

• Adds an ExpectedErrorKind::BackendUserError variant matching the canonical wire shape "Backend returned <status> ..." produced by IntegrationClient::post/get and ComposioClient::delete.
• Classifies 4xx except 408/429 (those stay actionable — 408/429 are transient, and a sustained 429 rate-limit cliff still needs to surface).
• Switches three call sites — src/openhuman/integrations/client.rs::post, ::get, src/openhuman/composio/client.rs::delete — from raw report_error to report_error_or_expected so the classifier suppresses user-input / auth-state shapes.
• 5xx remains actionable (server bugs should still reach Sentry).

Why

OPENHUMAN-TAURI-BC: a user submitted SharePoint authorize without the required Tenant Name field. Composio correctly returned 400 ConnectedAccount_MissingRequiredFields, the UI surfaced the structured error to the user via toast, but the integrations client still fired a Sentry event with no remediation path — the request was malformed by the user's input, not by our code.

Per the established "surface the deeper fix" rule:

• UI pre-flight validation of every Composio toolkit's required fields would prevent these requests entirely, but requires the UI to track Composio's per-toolkit field schemas (which vary and change over time) — that's a non-trivial product feature, not a bug fix.
• The current UX (submit → backend validates → toast) is correct. Only the Sentry noise needs to stop.

Mirrors the existing NetworkUnreachable (OPENHUMAN-TAURI-32) and TransientUpstreamHttp (OPENHUMAN-TAURI-5Z) skips — both wire user-environment shapes through the same report_error_or_expected path.

Fixes OPENHUMAN-TAURI-BC

Test plan

• `cargo check --tests` — clean (only pre-existing warnings unrelated to this change)
• `cargo test --lib core::observability` — 19 passed (2 new tests)
• `cargo test --lib openhuman::integrations::client` — 13 passed (2 new tests)
• `cargo test --lib openhuman::composio::client` — 27 passed (call-site change compiles + existing behavior intact)
• New tests:
  • `classifies_backend_user_error_responses` — 400/401/403/404/422/451 + the exact OPENHUMAN-TAURI-BC wire shape
  • `does_not_classify_transient_or_server_backend_errors_as_user_error` — 408/429/500/502/503/504 stay actionable
  • `post_400_user_input_failure_classifies_as_backend_user_error` — HTTP-driven regression pinning the bail format to the classifier
  • `post_500_remains_actionable` — counterpart guard

Summary by CodeRabbit

• Bug Fixes

  • Improved backend error handling: certain non-transient 4xx backend responses are now treated as non-actionable user/authentication issues, reducing noisy error alerts and preserving actionable reporting for 5xx and transient errors.

• Tests

  • Added regression tests to ensure correct classification of backend 4xx vs 5xx responses.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 747624c7-ec4c-4df9-957f-b324a2e75dd1

📥 Commits

Reviewing files that changed from the base of the PR and between 15bb8b2 and c8a96c2.

📒 Files selected for processing (1)

• src/core/observability.rs

🚧 Files skipped from review as they are similar to previous changes (1)

• src/core/observability.rs

---

📝 Walkthrough

Walkthrough

Adds ExpectedErrorKind::BackendUserError and is_backend_user_error_message to detect backend-formatted 4xx messages (excluding 408/429), routes client non-2xx responses through report_error_or_expected, and logs classified backend 4xx as tracing::warn! breadcrumbs; tests verify 4xx classification and 5xx retention.

Changes

Backend user-error classification and observability routing

Layer / File(s)	Summary
Backend user error classification contract and detection src/core/observability.rs	ExpectedErrorKind gains BackendUserError. is_backend_user_error_message parses Backend returned <status> ... and expected_error_kind maps non-transient 4xx (excluding 408/429) to BackendUserError.
Observability reporting for backend user errors src/core/observability.rs	report_expected_message recognizes BackendUserError and emits a tracing::warn! breadcrumb, suppressing Sentry error events for these cases.
Client HTTP error path routing to classification src/openhuman/composio/client.rs, src/openhuman/integrations/client.rs	ComposioClient::raw_delete, IntegrationClient::post, and IntegrationClient::get now call report_error_or_expected(...) instead of report_error(...) on non-2xx responses, enabling the new classification to demote certain 4xx into warn breadcrumbs while leaving 5xx actionable.
Regression and unit tests for classification behavior src/openhuman/integrations/client_tests.rs, src/core/observability.rs	New integration tests verify a 400 composio response classifies as BackendUserError and a 500 remains actionable; unit tests cover multiple 4xx classifications and exclusion of transient 408/429 and 5xx, plus non-matching messages.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related issues

• Transient upstream failures reach Sentry as errors, drowning real bugs #1608: Both touch observability reporting and client callsites to adjust how backend HTTP failures are classified and surfaced.

Possibly related PRs

• tinyhumansai/openhuman#1669: Similar extension of ExpectedErrorKind and routing through report_error_or_expected/report_expected_message.
• tinyhumansai/openhuman#1623: Also updates ExpectedErrorKind and suppresses Sentry for specific expected message patterns.
• tinyhumansai/openhuman#1330: Modifies the same client non-success paths and backend error handling that interact with the new classification.

Suggested labels

working

Suggested reviewers

• senamakel

Poem

🐰 I hopped through logs with careful cheer,
Found four-hundred whispers, calm and clear,
Warn breadcrumbs placed where users erred,
Five-hundreds still get flagged and heard,
A tidy hop — observability, my dear.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the primary change: adding BackendUserError classification for backend 4xx responses in observability, with a specific ticket reference.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[senamakel]

resolve merge conflicts

[senamakel]

pr-manager update (automated)

Merge conflicts in src/core/observability.rs and src/openhuman/integrations/client.rs have been resolved and pushed to senamakel/openhuman:pr/1676 (commit c8a96c2).

Quality suite results:

• cargo fmt — clean (no changes needed)
• cargo check (core + Tauri shell) — clean (pre-existing warnings only, none from this PR)
• cargo test --lib core::observability — 30/30 passed
• cargo test --lib openhuman::integrations — 69/69 passed
• cargo test --lib openhuman::composio — 367/367 passed
• Pre-push hooks (Prettier, ESLint, rust format check, cargo check) — all passed

Note: This branch is on senamakel/openhuman:pr/1676 (the maintainer's fork copy), not CodeGhost21/openhuman. CodeRabbit has already APPROVED the PR. The senamakel CHANGES_REQUESTED review (resolve merge conflicts) is now addressed.