[BUG] OpenRouter pipe routing only after delay

[MoweME]

App Version

2.4.3 (91)

Platform

• Android
• iOS

How you installed it

Google Play

What happened?

Every request takes a 60-second delay if a 3rd-party connector such as Open-WebUI-OpenRouter-pipe is used.
Three dots (loading indicator) are blinking in the chat while this 60 seconds

What should have happened?

The request should be instantly routed through the pipeline

How to reproduce

1. Install and set up Open-WebUI-OpenRouter-pipe
2. Select a model routed through the pipe in the app
3. Begin to chat

Does this happen every time?

Yes, every time

When did this start?

No response

Screenshots

WhatsApp.Video.2026-02-23.at.09.49.14.mp4

Logs

No response

[DennisHenne]

I can confirm this issue on the newest ios version too...

[cwawak]

Same here too

[cwawak]

I've spent a little time trying to solve this, and here's where I am as of today.

Issue: ~50 second delay before messages route through OpenRouter Pipe when using Conduit (iOS), but works instantly with web UI on same network.

Timeline:

• _execute_pipe_job fires immediately (2ms to return 200)
• But process_request doesn't start for ~50 seconds
• This happens before any OpenRouter API calls

Key findings:

1. The delay is NOT in OpenWebUI's model validation (the direct: true check)
2. The delay is NOT in the OpenRouter Pipe's catalog refresh
3. The delay IS in OpenWebUI's pipeline execution - something is blocking for 50 seconds before the pipe's process_request runs
4. Same server, same network, same user - only Conduit has this issue, web UI works instantly

Suspected cause: Conduit sends a synthetic modelItem while web UI sends the real model from OpenWebUI's cache. This difference likely triggers slow validation/fallback logic in OpenWebUI's pipeline execution.

What I tried:

1. Conduit: Adding direct: true to modelItem - Would have fixed OpenWebUI's model validation, but would break routing because Conduit's synthetic modelItem lacks the pipe field that OpenWebUI uses to route to the correct pipe function
2. OpenRouter Pipe: Three performance fixes:
   • Parallelized GET /models and GET /endpoints/zdr calls (60s → 30s worst case)
   • Added stale-while-revalidate to serve cached data immediately while refreshing in background
   • Reduced HTTP timeout from 30s to 10s
   • These pipe fixes did NOT resolve the issue

What I didn't try:

• Removing the modelItem entirely - This would force OpenWebUI to look up the model from its cache (like the web UI does). Could be tested by passing null for modelItem in the sendMessage call.

Next step needed: Capture what's different in Conduit's /api/chat/completions request body vs web UI to identify what triggers the 50-second delay.

[cwawak]

After more investigation, I think I found the root cause:

The Problem: The 60-second delay is triggered by Conduit's request payload. When Conduit sends a request with ALL THREE of session_id, chat_id, AND message_id (the id field), OpenWebUI routes the request through an async task queue via Redis. This is designed for background processing but adds ~60 seconds of latency for synchronous requests.

The Fix: Remove these identifiers from the request payload to bypass the async task queue:

# In OpenWebUI's main.py (lines 1929-1944), this condition triggers async processing:
if session_id and chat_id and message_id:
    # Routes to background task queue via Redis

I've implemented a fix in Conduit that removes session_id, id (messageId), and chat_id from the /api/chat/completions request. This forces OpenWebUI to return the response via SSE streaming instead of queuing it as a background task.

Current status:

• ✅ 60-second delay is eliminated (HTTP completes in ~2-3 seconds now)
• ✅ Response streams properly via SSE
• 🔄 Still refining: Occasional chunk boundary issues (words concatenating) and duplication from both HTTP and WebSocket delivery - working on these

The key insight was that the web UI doesn't include these identifiers in its /api/chat/completions calls, which is why it doesn't experience the delay.

[cwawak]

Update: PR #384 now points to the refactor branch that normalizes SSE content into clean deltas before the UI. This fixes the 60s delay, restores usage/cost info, and resolves duplicated responses + “Thesky” spacing in my testing on iOS. If folks can test on their setups, I’d appreciate confirmation.

[MoweME]

Thank you for your work. I did not had the time to troubleshoot this deeply, but will test it ASAP.