refactor(api): migrate callers to effective_backend_api_url#1764
Merged
senamakel merged 1 commit intoMay 15, 2026
Merged
Conversation
Rename effective_integrations_api_url → effective_backend_api_url and migrate 38+ call sites that hit hosted backend services (billing, team, credentials, channels, voice, webhooks, socket, jsonrpc, meet_agent) away from effective_api_url. Inference callers (providers/openhuman_backend, embeddings/cloud) and diagnostic callers (doctor/core, config/ops) correctly remain on effective_api_url. Fixes local-AI users getting broken billing/team/voice when they override OPENHUMAN_API_URL for inference. Closes tinyhumansai#1663
Contributor
📝 WalkthroughWalkthroughThis PR migrates backend API callers from ChangesBackend API URL Resolver Migration
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/api/config.rs (1)
203-212:⚠️ Potential issue | 🟠 Major | ⚡ Quick winRedact user-provided URL before emitting fallback warning.
local_urlis logged verbatim. Ifconfig.api_urlincludes credentials or query tokens, this can leak secrets into logs. Please sanitize or omit the raw URL before logging.As per coding guidelines, "Never log secrets, raw JWTs, API keys, credentials, or full PII in debug logs; redact or omit sensitive fields".Suggested patch
fn warn_backend_url_fallback_once(local_url: &str) { use std::sync::Once; static WARNED: Once = Once::new(); WARNED.call_once(|| { + let redacted_local_url = url::Url::parse(local_url) + .map(|mut u| { + let _ = u.set_username(""); + let _ = u.set_password(None); + u.set_query(None); + u.set_fragment(None); + u.to_string() + }) + .unwrap_or_else(|_| "<invalid-url>".to_string()); + tracing::warn!( - local_url = %local_url, + local_url = %redacted_local_url, "[api/config] config.api_url looks like a local-AI endpoint; \ - integrations base will fall back to env/default backend so \ + backend base will fall back to env/default backend so \ /agent-integrations/* requests don't 404 against your local LLM" ); }); }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/api/config.rs` around lines 203 - 212, The warn_backend_url_fallback_once function currently logs the user-provided local_url verbatim; update this to redact sensitive parts before logging by parsing local_url (using the URL parser available in the codebase or std libraries), remove or mask userinfo (username:password) and query string/token parameters, and then log a sanitized form (e.g., scheme://host[:port]/path with query and userinfo removed or replaced with "<redacted>"). Ensure the change is applied where local_url is passed into tracing::warn! so the logged value no longer contains credentials or raw tokens.
🧹 Nitpick comments (1)
src/openhuman/integrations/client.rs (1)
278-286: ⚡ Quick winUpdate inline comment to reflect generalized backend resolver.
The inline comment on line 278 still refers to the "integrations-specific resolver", but per the PR description,
effective_backend_api_urlis now the generalized resolver for all backend-proxied calls (billing, team, webhooks, referral, credentials, channels, voice, etc.), not just integrations. The function-level doc comment (lines 262-269) correctly describes it as the "backend resolver" — the inline comment should match.📝 Suggested doc update
- // Use the integrations-specific resolver: when `config.api_url` is set + // Use the backend resolver: when `config.api_url` is set // to a local-AI endpoint (Ollama, vLLM, …), it would still be perfect // for `/v1/chat/completions`, but reusing it as the base for backend // integration paths produces URLs like🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/openhuman/integrations/client.rs` around lines 278 - 286, Update the inline comment above the call to effective_backend_api_url(&config.api_url) to describe it as the generalized "backend resolver" for all backend-proxied calls (billing, team, webhooks, referral, credentials, channels, voice, integrations, etc.) rather than an "integrations-specific resolver"; reference the function name effective_backend_api_url and keep the note about avoiding local-LLM base URLs producing 404s so the behavior explanation remains accurate.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@src/api/config.rs`:
- Around line 203-212: The warn_backend_url_fallback_once function currently
logs the user-provided local_url verbatim; update this to redact sensitive parts
before logging by parsing local_url (using the URL parser available in the
codebase or std libraries), remove or mask userinfo (username:password) and
query string/token parameters, and then log a sanitized form (e.g.,
scheme://host[:port]/path with query and userinfo removed or replaced with
"<redacted>"). Ensure the change is applied where local_url is passed into
tracing::warn! so the logged value no longer contains credentials or raw tokens.
---
Nitpick comments:
In `@src/openhuman/integrations/client.rs`:
- Around line 278-286: Update the inline comment above the call to
effective_backend_api_url(&config.api_url) to describe it as the generalized
"backend resolver" for all backend-proxied calls (billing, team, webhooks,
referral, credentials, channels, voice, integrations, etc.) rather than an
"integrations-specific resolver"; reference the function name
effective_backend_api_url and keep the note about avoiding local-LLM base URLs
producing 404s so the behavior explanation remains accurate.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f71dbbaa-8b21-4ed3-a87c-e445774ae7ed
📒 Files selected for processing (17)
src/api/config.rssrc/api/mod.rssrc/core/jsonrpc.rssrc/openhuman/app_state/ops.rssrc/openhuman/billing/ops.rssrc/openhuman/channels/bus.rssrc/openhuman/channels/controllers/ops.rssrc/openhuman/credentials/ops.rssrc/openhuman/integrations/client.rssrc/openhuman/local_ai/gif_decision.rssrc/openhuman/meet_agent/brain.rssrc/openhuman/referral/ops.rssrc/openhuman/socket/schemas.rssrc/openhuman/team/ops.rssrc/openhuman/voice/cloud_transcribe.rssrc/openhuman/voice/reply_speech.rssrc/openhuman/webhooks/ops.rs
senamakel
approved these changes
May 15, 2026
This was referenced May 15, 2026
AusAgentSmith
pushed a commit
to AusAgentSmith/openhuman
that referenced
this pull request
May 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
effective_integrations_api_url→effective_backend_api_url(more general name for all backend-proxied calls)effective_api_urltoeffective_backend_api_urlproviders/openhuman_backend,embeddings/cloud) and diagnostic callers (doctor/core,config/ops) correctly remain oneffective_api_urlProblem
OPENHUMAN_API_URLsilently lose every backend feature outside Composio integrations — billing checks, team membership, referral, webhooks, credentials, channels, voiceSolution
effective_backend_api_urlalways resolves to the hosted backend (falls back toOPENHUMAN_INTEGRATIONS_API_URLenv → hardcoded prod URL), regardless of user's local-AI overrideeffective_api_urleffective_api_urlis preserved only for OpenAI-compatible inference endpoints that legitimately honor the user's local-AI overridenormalize_integrations_api_base_url→normalize_backend_api_base_url,warn_integrations_url_fallback_once→warn_backend_url_fallback_onceSubmission Checklist
## Related— N/A: no feature ID changesdocs/RELEASE-MANUAL-SMOKE.md) — N/A: no release-cut surface changesCloses #NNNin the## RelatedsectionImpact
effective_api_urlstill exists for inference callers;effective_backend_api_urlis the renamedeffective_integrations_api_urlwith same semanticsRelated