Skip to content

[Bug]: Web search is still triggered when the internet toggle is off if tavily_api_key is configured (v0.24.0) #14051

@zzming-tjufe

Description

@zzming-tjufe

Self Checks

  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (Language Policy).
  • Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
  • Please do not modify this template :) and fill in all the required fields.

RAGFlow workspace code commit ID

unknown

RAGFlow image version

v0.24.0

Other environment information

- Deployment: local(docker)
- Browser: Chrome
- OS: Windows 11

Actual behavior

After configuring and saving a valid tavily_api_key, web search is still triggered even when the internet toggle is off in the chat UI.

From the user side, the toggle does not seem to take effect:

  • when no Tavily API key is configured, questions requiring real-time external information cannot be answered
  • after saving a Tavily API key, the same question can still get an accurate answer even though the internet toggle remains off

This makes the internet toggle appear ineffective.

Expected behavior

When the internet toggle is off, the chat flow should not call Tavily or any other web search path, even if tavily_api_key is already configured in prompt_config.

In other words:

  • internet = false should disable web search
  • having a saved Tavily API key should only make web search available, not automatically active

Steps to reproduce

1. Start RAGFlow `v0.24.0`
2. Open the Chat page
3. Make sure no Tavily API key is configured
4. Ask a question that clearly requires external real-time information, for example:  
   `What was the weather in [City] in March 2026?`
5. Observe that the system cannot answer it with external real-time information
6. Configure and save a valid Tavily API key
7. Keep the **internet toggle off**
8. Ask the same question again
9. Observe that the assistant still returns an accurate answer that appears to come from web search

Additional information

I checked the code path and found that this may be caused by a frontend-backend contract mismatch:

  • the frontend sends internet: true/false in the chat request
  • but the backend chat flow does not appear to consume this field
  • Tavily retrieval is triggered as long as prompt_config.tavily_api_key exists

Relevant code paths I found:

Frontend sends internet

web/src/pages/next-chats/hooks/use-send-chat-message.ts

const res = await send(
  api.completionUrl(chatId!, sessionId),
  {
    messages: [...],
    reasoning: enableThinking,
    internet: enableInternet,
  },
  controller,
);

Frontend internet toggle visibility depends on Tavily key

web/src/pages/next-chats/chat/use-show-internet.ts

export function useShowInternet() {
  const { data: currentDialog } = useFetchChat();
  return !isEmpty(currentDialog?.prompt_config?.tavily_api_key);
}

Backend normal chat path triggers Tavily based on tavily_api_key

api/db/services/dialog_service.py

if prompt_config.get("tavily_api_key"):
    tav = Tavily(prompt_config["tavily_api_key"])
    tav_res = tav.retrieve_chunks(" ".join(questions))
    kbinfos["chunks"].extend(tav_res["chunks"])
    kbinfos["doc_aggs"].extend(tav_res["doc_aggs"])

Reasoning path also triggers Tavily based on tavily_api_key

rag/advanced_rag/tree_structured_query_decomposition_retrieval.py

if self.prompt_config.get("tavily_api_key"):
    tav = Tavily(self.prompt_config["tavily_api_key"])
    tav_res = tav.retrieve_chunks(search_query)

I also could not find an obvious backend read path for internet in the Python side.

So the current behavior seems to be:

  • frontend toggle state is sent
  • backend does not use it
  • Tavily is triggered whenever tavily_api_key exists

This may explain why web search still runs even when the internet toggle is off.

Metadata

Metadata

Assignees

Labels

🐞 bugSomething isn't working, pull request that fix bug.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions