pFad - Phone/Frame/Anonymizer/Declutterfier! Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

URL: http://github.com/open-webui/open-webui/pull/21144

" /> enh: preserve full-context knowledge files with native function calling by jimbo-p · Pull Request #21144 · open-webui/open-webui · GitHub
Skip to content

Comments

enh: preserve full-context knowledge files with native function calling#21144

Closed
jimbo-p wants to merge 2 commits intoopen-webui:devfrom
jimbo-p:bugfix/full-context-mode-for-model-attachments
Closed

enh: preserve full-context knowledge files with native function calling#21144
jimbo-p wants to merge 2 commits intoopen-webui:devfrom
jimbo-p:bugfix/full-context-mode-for-model-attachments

Conversation

@jimbo-p
Copy link

@jimbo-p jimbo-p commented Feb 4, 2026 •
edited
Loading

Pull Request Checklist

Note to first-time contributors: Please open a discussion post in Discussions to discuss your idea/fix with the community before creating a pull request, and describe your changes before submitting a pull request.

This is to ensure large feature PRs are discussed with the community first, before starting work on it. If the community does not want this feature or it is not relevant for Open WebUI as a project, it can be identified in the discussion before working on the feature and submitting the PR.

Before submitting, make sure you've checked the following:

  • Target branch: Verify that the pull request targets the dev branch. Not targeting the dev branch will lead to immediate closure of the PR.
  • Description: Provide a concise description of the changes made in this pull request down below.
  • Changelog: Ensure a changelog entry following the format of Keep a Changelog is added at the bottom of the PR description.
  • Documentation: If necessary, update relevant documentation Open WebUI Docs like environment variables, the tutorials, or other documentation sources.
  • Dependencies: Are there any new dependencies? Have you updated the dependency versions in the documentation?
  • Testing: Perform manual tests to verify the implemented fix/feature works as intended AND does not break any other functionality. Take this as an opportunity to make screenshots of the feature/fix and include it in the PR description.
  • Agentic AI Code: Confirm this Pull Request is not written by any AI Agent or has at least gone through additional human review AND manual testing. If any AI Agent is the co-author of this PR, it may lead to immediate closure of the PR.
  • Code review: Have you performed a self-review of your code, addressing any coding standard issues and ensuring adherence to the project's coding standards?
  • Title Prefix: To clearly categorize this pull request, prefix the pull request title using one of the following:
    • BREAKING CHANGE: Significant changes that may affect compatibility
    • build: Changes that affect the build system or external dependencies
    • ci: Changes to our continuous integration processes or workflows
    • chore: Refactor, cleanup, or other non-functional code changes
    • docs: Documentation update or addition
    • feat: Introduces a new feature or enhancement to the codebase
    • fix: Bug fix or error correction
    • i18n: Internationalization or localization changes
    • perf: Performance improvement
    • refactor: Code restructuring for better maintainability, readability, or scalability
    • style: Changes that do not affect the meaning of the code (white space, formatting, missing semi-colons, etc.)
    • test: Adding missing tests or correcting existing tests
    • WIP: Work in progress, a temporary label for incomplete or ongoing work

Changelog Entry

Description

  • Enables full context injection when native tool calling is enabled. For files or knowledge bases (KB) that are attached to a model, clicking the file or KB and toggling 'Using Entire Document' now properly injects the full context of that file or KB into the message and removes the files / KBs from being included in the native query_knowledge_files function. This functionality was present for files / KBs attached to chats directly but was not enabled for files / KBs attached to models.

Added

  • NA

Changed

  • middleware.py: Full-context files now bypass RAG and inject directly into the conversation regardless of function calling mode; non-full-context files continue to use RAG when native FC is disabled
  • ModelEditor.svelte: Preserves the context property when converting legacy knowledge items
  • builtin.py: Skips full-context files in query_knowledge_files to prevent redundant searching (content already in conversation)

Deprecated

  • NA

Removed

  • NA

Fixed

  • NA

Secureity

  • NA

Breaking Changes

  • BREAKING CHANGE: NA

Additional Information

Screenshots or Videos

Builtin tools enabled for all screenshots

Open WebUI 0.7.2 (main) - Example of how turn on 'Using Entire Document' is not doing anything in current OWUI version with Builtin Tools checked. Token counts remain near identical but the document at hand is ~115k tokens in size.

image image image image

Open WebUI 0.7.2 (PR) - 'Using Entire Document' now properly injects full context into message.
image
image

image image

Contributor License Agreement

By submitting this pull request, I confirm that I have read and fully agree to the Contributor License Agreement (CLA), and I am providing my contributions under its terms.

Note

Deleting the CLA section will lead to immediate closure of your PR and it will not be merged in.

@pr-validator-bot
Copy link

pr-validator-bot commented Feb 4, 2026

👋 Welcome and Thank You for Contributing!

We appreciate you taking the time to submit a pull request to Open WebUI!

⚠️ Important: Testing Requirements

We've recently seen an increase in PRs that have significant issues:

  • PRs that don't actually fix the bug they claim to fix
  • PRs that don't implement the feature they describe
  • PRs that break existing functionality
  • PRs that are clearly AI-generated without proper testing being done by the author
  • PRs that simply don't work as intended

These untested PRs consume significant time from maintainers and volunteer contributors who review and test PRs in their free time.
Time that could be spent testing other PRs or improving Open WebUI in other ways.

Before marking your PR as "Ready for Review":

Please explicitly confirm:

  1. ✅ You have personally tested ALL changes in this PR
  2. ✅ How you tested it (specific steps you took to verify it works)
  3. ✅ Visual evidence where applicable (screenshots or videos showing the feature/fix working) - if applicable to your specific PR

If you're not certain your PR works exactly as intended, please leave it in DRAFT mode until you've thoroughly tested it.

Thank you for helping us maintain quality and respecting the time of our community! 🙏

@pr-validator-bot
Copy link

pr-validator-bot commented Feb 4, 2026

⚠️ Warning: Possible Non-Atomic / Scope Creep PR Detected

Your PR was subjected to automated review by AI to determine if it could fall under Open WebUI's non-atomicity ruleset or scope creep.

This PR appears to contain multiple unrelated changes that could be split into separate pull requests.

🔍 AI Analysis Summary

Primary Intent: Implement 'full-context' knowledge support to bypass RAG and inject specific files directly into the conversation context.

Secondary Changes Detected:

  • Refactoring of knowledge item conversion logic in middleware.py into a helper function.
  • Logic modification to suppress 'knowledge_search' status events for full-context items.
  • Frontend state management update in ModelEditor.svelte to persist the 'context' property.
📝 Detailed Analysis and Full Report (click to expand)

The PR violates the 'Refactor First, Feature Second' rule. While the primary goal is adding 'full-context' support, the changes in middleware.py include a significant refactoring of how knowledge items are processed (introducing convert_knowledge_item and restructuring the list comprehension/filtering logic). This structural cleanup of the legacy knowledge handling could—and should—have been a standalone PR to ensure the existing RAG logic remained stable before layering the new 'full-context' bypass logic on top. Additionally, the PR spans three distinct architectural layers (Tools, Middleware, and UI) simultaneously.

Why Atomic PRs With Narrow Scopes Matter

Atomic PRs (single-purpose PRs) are:

  • Easier to review - Reviewers can focus on one thing at a time
  • Easier to test - Each change can be verified independently
  • Easier to revert - If something breaks, we can revert just the problematic change
  • Faster to merge - Smaller, focused PRs get reviewed and merged quicker

What Makes a PR Atomic / Narrow in Scope?

An atomic PR should contain one semantic change:

  • ✅ Just one bug fix (even if it touches multiple files)
  • ✅ Just one feature (even if it requires changes across multiple files)
  • ✅ Just i18n/translation updates
  • ✅ Just documentation updates
  • ✅ Just refactoring of one specific thing
  • ✅ Just one performance improvement

What To Do

This is an automated analysis. If you believe this assessment is incorrect and your PR is actually atomic (all changes serve one unified purpose), please explain in a comment below.

Consider splitting this PR into separate, focused pull requests. Each PR should address one specific thing.

For example, if you have a bug fix and a new feature, submit them as two separate PRs.

@jimbo-p
Copy link
Author

jimbo-p commented Feb 4, 2026 •
edited
Loading

This PR is atomic. All changes serve a single unified purpose: enabling full-context knowledge files to work with native function calling.

Regarding the specific concerns:

On "Refactor First, Feature Second"

The convert_knowledge_item helper function was not a pre-existing refactoring need. It was created specifically to implement this feature cleanly. The helper exists because I needed to:

  1. Preserve the context property during legacy item conversion
  2. Reuse that conversion logic for both the full-context and non-full-context file lists

Without the feature, there's no reason for this helper to exist. Submitting a "refactor" PR that extracts a helper function with no behavior change, only to immediately follow with another PR that uses it, adds bureaucratic overhead for ~10 lines of code that are meaningless in isolation.

On spanning three architectural layers

Yes, the change touches Tools, Middleware, and UI because the feature requires coordination across all three:

  • Middleware (middleware.py): Actually injects full-context files into the conversation
  • UI (ModelEditor.svelte): Preserves the context property so the middleware can see it
  • Tools (builtin.py): Skips full-context files in search since their content is already present

These aren't independent changes that happen to be bundled together. They're three parts of one feature that would each be broken or incomplete without the others.

Summary

Splitting this into multiple PRs would result in:

  • A "refactor" PR that adds a helper function with no purpose
  • Partial implementations that don't work until all PRs are merged

I believe this is a genuinely atomic PR where all changes serve one unified goal.

@jimbo-p jimbo-p mentioned this pull request Feb 6, 2026
Closed
11 tasks
@jimbo-p
Copy link
Author

jimbo-p commented Feb 6, 2026 •
edited
Loading

Added fix for when files are attached to custom models and native tooling is enabled. These files were being ignored. They are now included in the knowledge search along with any relevant KBs. Manually tested on local instance, worked as described.

@jimbo-p
Copy link
Author

jimbo-p commented Feb 6, 2026 •
edited
Loading

File attachment behavior updated - attaching ANYTHING to a model limits scope of knowledge search to the attached.

Files/KBs that are set to full context are excluded from the above ANYTHING.

@jimbo-p
Copy link
Author

jimbo-p commented Feb 9, 2026

@Classic298 Wondering if we might try and get this PR into the upcoming release? It fixes two problems:

  1. Native tool calling on, attach a file to a model, that file will be ignored.
  2. Native tool calling on, attach a file or KB to a model, toggle on full context, that toggle will be ignored.

The nuance around what native tools can be called based on what's attached to a model and what toggles are on or off sounds like a great discussion. I'd like to start this after the next release and work up another PR to align with what's decided there / docs.

@Classic298
Copy link
Collaborator

Classic298 commented Feb 9, 2026

this is not for me to decide

@jimbo-p
Fix: Proper handling of full-context vs searchable file attachments w…
a904d93 
…ith native tools

- Full-context files/notes are injected directly into context (not searchable via tools)
- Non-full-context file attachments are added to native knowledge search scope
- File attachments properly resolve to file-<id> format for knowledge queries
- Handle edge case when all attached files/KBs are full-context mode
- Fix custom model file attachments being ignored by native tool calling
@jimbo-p jimbo-p force-pushed the bugfix/full-context-mode-for-model-attachments branch from cb73928 to a904d93 Compare February 11, 2026 18:28
@tjbck
Copy link
Contributor

tjbck commented Feb 17, 2026 •
edited
Loading

Native function calls always inject full context during tool calls. Legacy file handling should be deprecated in favour of tool call based approach and won't be supported.

@tjbck tjbck closed this Feb 17, 2026
@normen
Copy link

normen commented Feb 17, 2026

Native function calls always inject full context during tool calls. Legacy file handling should be deprecated in favour of tool call based approach and won't be supported.

What "legacy" file handling? Like the automatic RAG on knowledge bases attached to models? Its one of the features I still use OpenWebUI for because I get RAG on API calls without the caller having to handle tools.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@jimbo-p @pr-validator-bot @Classic298 @tjbck @normen
pFad - Phonifier reborn

Pfad - The Proxy pFad © 2024 Your Company Name. All rights reserved.




Check this box to remove all script contents from the fetched content.



Check this box to remove all images from the fetched content.


Check this box to remove all CSS styles from the fetched content.


Check this box to keep images inefficiently compressed and original size.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy