[Bug]: Switching LLM/embedding provider via the Settings/Onboarding API blocks flows with "custom components are not allowed"

[mjobrien05]

OpenRAG Version

0.5.0 (main @ 1e228bb, and reproduced against later commits — the relevant default is unchanged as of this filing)

Deployment Method

Docker

Operating System

macOS 24.6.0

Affected Area

Settings (configuration, model providers), Chat (chat interface, conversations, AI responses), Ingestion (document processing, upload, Docling)

Bug Description

After changing the LLM/embedding provider via the API (POST /onboarding or POST /settings), both /v1/chat and ingestion fail with:

500 {"message": "Error running graph: Error building Component Agent: ... Flow build blocked: custom components are not allowed: OpenRAG Embeddings (OpenAICompatibleEmbedding-...), OpenRAG LLM (OpenAICompatibleLLM-...)"}

Root cause: Langflow's own component-trust validation (lfx/utils/flow_validation.py) is a real security feature (allow_custom_components Langflow setting, false by default) meant to stop untrusted user-authored flow code from running. OpenRAG's own first-party OpenAICompatibleLLM/OpenAICompatibleEmbedding wrapper components get dynamically substituted into the flow when a provider is changed via POST /onboarding / POST /settings (src/api/settings/langflow_sync.py), and this substitution isn't recognized as trusted by Langflow's hash-based validator, so the flow gets blocked as if it were untrusted user code — even though it's OpenRAG's own generated configuration.

Steps to Reproduce

1. Complete initial onboarding with any provider (e.g. OpenAI).
2. Change the LLM or embedding provider via POST /onboarding or POST /settings (not the guided UI onboarding flow — unconfirmed whether that path avoids this the same way, or simply isn't exercised the same way).
3. Attempt /v1/chat or document ingestion.

Expected Behavior

Switching providers via the API should produce a working flow, same as switching via the UI onboarding wizard.

Actual Behavior

500 on both chat and ingestion, citing OpenAICompatibleLLM/OpenAICompatibleEmbedding — OpenRAG's own generated components — as disallowed custom components.

Workaround

Set LANGFLOW_ALLOW_CUSTOM_COMPONENTS=true. Safe on a local single-user instance, not something you'd want on a multi-tenant deployment without understanding the security trade-off being made (it globally disables the untrusted-component guard, not just for OpenRAG's own generated components).

Suggested Fix

Either register OpenRAG's own generated component code as trusted (compute/allowlist its hash at generation time) so dynamic provider switching doesn't require globally disabling the untrusted-component guard, or document this requirement clearly wherever provider-switching via the API is documented.

Additional Context

I noticed #2263 ("Litellm OpenAI compatible router") — a large, currently-stale open PR reworking provider handling — has this exact failure string as an explicit test-plan item ("Confirm OpenRAG LLM / Embeddings / OpenSearch nodes are present and ingest is not blocked with 'custom components are not allowed'"), so the team is clearly already aware this needs to hold. Flagging this as a standalone, reproducible issue in case that PR stalls further or a narrower fix lands first.

Checklist

• I have searched existing issues to ensure this bug hasn't been reported before.
• I have provided all the requested information.