fix: agent file context gating to support document-capable models

[jony376]

Fixes #35175

Problem

Agent runtime was incorrectly tying file context strictly to vision capability, causing document uploads to be ignored even when the model supported documents. This change aligns file forwarding with actual model file capabilities while preserving existing safeguards for unsupported models.

Summary

This PR fixes a bug where uploaded files were not passed to Agent context unless the selected model had vision support.
Agent file forwarding now correctly works for models that support either vision or document, which resolves the behavior reported in #35175.

[jony376]

@dosu

please check this PR. why merging is blocked?

[dosubot]

Thanks for the PR! I reviewed the changes. Here's a summary:

What the PR does: Changes the file-gating condition in BaseAgentRunner.__init__ (and two frontend debug components) from checking only ModelFeature.VISION to checking ModelFeature.VISION or ModelFeature.DOCUMENT, so that uploaded documents are forwarded to models that support the document feature [1].

Enum validity — looks good. Both ModelFeature.DOCUMENT (backend, from the graphon package) [2] and ModelFeatureEnum.document (frontend) [3] are valid, existing enum members.

Tests — look good. Two new unit tests cover the document-model and no-file-feature scenarios [4].

Potential concern — image_detail_config passed for document files. Downstream in both FunctionCallAgentRunner._organize_user_query() and CotChatAgentRunner._organize_user_query(), when self.files is non-empty the code retrieves image_config.detail and passes it as image_detail_config to file_manager.to_prompt_message_content() [5]. With this PR, self.files can now contain document files. Based on codebase usage patterns, the to_prompt_message_content() function (from the external graphon library) appears to handle different file types independently — documents become DocumentPromptMessageContent and the image detail config is likely ignored for non-image files. The placeholder logic also already differentiates [image] vs [file] [6]. So this should be safe, but it's worth verifying that to_prompt_message_content() doesn't raise when receiving image_detail_config for a non-image file.

One thing that may be missing: The frontend changes only cover the two debug components (chat-item.tsx and debug-with-single-model/index.tsx) [7]. If there are other frontend paths that send files to the agent API (e.g., the published app chat interface), they may also need the same || supportDocument condition to avoid stripping document files before they reach the backend. Worth double-checking.

Overall the change is straightforward, correctly scoped to the reported issue (#35175), and has good test coverage. The main things to verify are:

1. That to_prompt_message_content() gracefully handles the image_detail_config param for document files.
2. Whether any other frontend send paths also need the document feature check.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[jony376]

@dosu
why merging is bloocked?

[dosubot]

I can't see the exact details in the screenshot (it rendered as raw image data), but based on the repository's merge requirements, the most common reasons a PR would be blocked from merging are:

1. Required CI checks haven't passed yet — The repo runs style checks, API tests, web tests, and more depending on which files changed [1]. Your PR modifies both Python and TypeScript files, so both backend and frontend checks need to pass.
2. Maintainer review required — The repo likely requires at least one approving review from a maintainer before merging.
3. PR title format — PR titles must follow semantic commit conventions (e.g., fix: ..., feat: ...). Your current title "Fix agent file context gating to support document-capable models" doesn't have a conventional prefix like fix:.

I'd suggest checking the "Checks" tab on the PR to see which specific checks are failing or pending, and whether any reviews are still required. If it's the PR title, renaming it to something like fix: agent file context gating to support document-capable models should resolve that blocker.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[jony376]

@dosu

I fixed title.

I don't receive this github-actions comment

[dosubot]

Unfortunately I couldn't clearly read the screenshot, and the PR metadata I can access doesn't include the live merge status or check results.

That said, based on the repository's setup, the merge block is most likely due to one of these:

1. Required status checks still pending or failing — The repo runs several CI checks on PRs (style checks, API tests, web tests, etc.) [1]. Since your PR touches both Python and TypeScript files, both backend and frontend checks need to pass. Check the "Checks" tab on the PR to see if any are failing or still running.

2. Maintainer review required — Branch protection rules (configured in repo settings, not visible to me) likely require at least one approving review from a maintainer before merging.

3. GitHub Actions environment restrictions for forks — If you're submitting from a fork, some GitHub Actions may not have access to repository secrets, which can cause certain checks to fail or not run at all. This could also explain why you're not receiving the expected github-actions comment — some workflows may be skipped or restricted for fork-based PRs.

Could you share what the merge blocking message says specifically? That would help narrow it down.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[jony376]

@dosu
Could you please review or approve the workflows if needed? Thanks!

[dosubot]

I'm not able to approve or trigger GitHub Actions workflows — I don't have permissions to do that. Only repository maintainers with write access can approve workflow runs for first-time contributors from forks.

Since this is likely your first PR to the langgenius/dify repo from a fork, GitHub requires a maintainer to manually approve the CI workflows before they can run. This is a GitHub security feature to prevent abuse of Actions compute on public repos.

You'll need to wait for a repository maintainer to approve the workflow runs. The PR itself looks solid from my earlier review — once a maintainer sees it and approves the workflows, CI should kick off.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[jony376]

@iamjoel Please check this PR

[jony376]

@laipz8200 Please check this PR

[jony376]

@dosu Why don't review my PR?

[dosubot]

I did review your PR earlier in this thread! Here's a quick recap of my findings:

• The core fix is correct — changing the file-gating condition from ModelFeature.VISION only to ModelFeature.VISION or ModelFeature.DOCUMENT is the right approach, and both enum values are valid.
• Tests look good — the two new unit tests properly cover the document-model and no-file-feature scenarios.
• One thing to verify — the downstream code in _organize_user_query() passes image_detail_config to file_manager.to_prompt_message_content() for all files, which should be fine for documents (likely ignored), but worth confirming.
• Possible gap — the frontend changes only cover the two debug components; other frontend paths that send files to the agent API may also need the || supportDocument check.

However, I can't approve the PR on GitHub — I don't have merge or approval permissions. You'll need a maintainer like @iamjoel or @laipz8200 (who you've already pinged) to formally review and approve it. Hang tight!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}