mirror of
https://github.com/langgenius/dify-official-plugins.git
synced 2026-07-21 17:45:23 -04:00
images Output from MinerU Plugin Not Passed to Next Node in Dify Workflow #805
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sisui-123 on GitHub (Nov 16, 2025).
Self Checks
Dify version
1.9.2
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
imagesfield in the output JSON (an array of objectsimagesfield from the previous node’s outputs.imagesis not available in the list of selectable input variables for the next node, even though other fields liketext,json,files, etc. are present.✔️ Expected Behavior
After the MinerU plugin node finishes processing a document and outputs the
imagesfield, the downstream node (e.g., a code node) should be able to see and selectimagesas an input variable.This would allow the next node to access and process the extracted image objects without any issues.
❌ Actual Behavior
Even though the MinerU plugin node outputs an
imagesfield containing the extracted images, the downstream node (e.g., code node) does not listimagesas an available input variable.As a result, the next node cannot access or use the extracted image objects, while other fields such as
text,json,files, andfull_zip_urlare accessible without any problem.@dosubot[bot] commented on GitHub (Nov 16, 2025):
Hi @sisui-123! I'm Dosu and I’m helping the dify-official-plugins team.
This issue happens because the workflow variable picker in Dify only exposes output fields from plugin/tool nodes if they are recognized and allowed by the frontend's schema/type logic. The MinerU plugin's
imagesfield is defined as an array of objects in its output schema, but unless the frontend's variable processing code (specifically, the logic inToolNodeDefault.getOutputVarsand the variable filter functions) recognizes and propagatesarray[object]types, fields likeimageswill be filtered out and not shown as selectable variables in downstream nodes—even though they are present in the output JSON. Other fields liketext,json,files, andfull_zip_urlare exposed because they match the expected types and structures in the variable picker logic.To make
imagesavailable in downstream nodes, the plugin's output schema must be correctly returned by the variable processing logic, and the filter must allowVarType.arrayObjectoutputs. This likely requires a code or configuration update to ensure array-of-object fields are included in the list of selectable variables for downstream nodes. No recent pull requests or issues address this directly, so this appears to be a current limitation or bug in the workflow variable exposure logic.Reference: frontend variable processing and schema handling
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@sisui-123 commented on GitHub (Nov 17, 2025):
@dosu
However, based on my testing, this does not fully match the behavior in the current version of Dify.
The json field from the MinerU plugin is also defined as array[object], yet it does appear in the workflow variable picker and can be selected normally in downstream nodes.
Only the images field—which has the same type (array[object])—is missing.
This suggests that the issue is not simply related to array-of-object types being filtered out globally. Instead, it may be a field-specific handling issue, or a bug in the variable-extraction logic that treats images differently from json, even though they share the same declared type.
@dosubot[bot] commented on GitHub (Nov 17, 2025):
You're right—this isn't a generic array[object] filtering issue. The root cause is in how Dify's variable picker logic handles plugin output schemas: fields like
imagesfrom MinerU are filtered out unless their schema includes explicit structured children metadata. Recent changes in the frontend (see code) tightened this filtering, so array fields without nested schema details (likeimages) get pruned, while built-in fields likejsonsurvive because they're part of the default tool output struct and bypass the aggressive child filtering.To work around this, you can try modifying the MinerU plugin's output schema to ensure the
imagesfield includes a detaileditemsschema (with properties for each image object). This should help the picker recognize and exposeimagesas a selectable variable downstream. If you control the plugin, update its output schema to match howjsonis defined, with explicit object properties for each array item.To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@simonjhy commented on GitHub (Dec 3, 2025):
We kindly request that Dify officially allow users to freely use the officially defined and supported data types as interfaces in custom plugins as soon as possible. The current restrictions are severely hindering many users from adopting Dify as a product. Lifting these limitations and allowing users to freely extend the functionality will undoubtedly significantly accelerate the popularity and promotion of Dify. Please do it ASAP !!!!!!!!!!
Official plugin can directly any output node, custom plugin should be approved to use all the data type defined by Dify, right?
@dosubot[bot] commented on GitHub (Dec 19, 2025):
Hi, @sisui-123. I'm Dosu, and I'm helping the dify-official-plugins team manage their backlog and am marking this issue as stale.
Issue Summary:
imagesfield was not available as an input variable downstream in Dify 1.9.2.images.imagesproperly.Next Steps:
Thank you for your understanding and contribution!