langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-23 04:55:28 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

using variables defined in structured_output returns null when model is set to gpt-4o #15917

New Issue
Closed
opened 2026-02-21 19:23:58 -05:00 by yindo · 1 comment
yindo commented 2026-02-21 19:23:58 -05:00
Owner
Copy Link
Copy Source

Originally created by @yoshi-1224 on GitHub (Aug 5, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.7.1

Cloud or Self Hosted

Cloud

Steps to reproduce

  1. Create any workflow with LLM node whose model is set up gpt-4o and structured output schema is defined
  2. In the following node (say "End"), refer to the variable defined in the structured output

Screenshot for step 1
Image

Screenshot for step 2
Image

✔️ Expected Behavior

End node will output the value inside the variable correctly. In this case, easy_script contains segments

❌ Actual Behavior

easy_script is null when model is gpt-4o. However, when 4o-mini is used, it works.

I think I know the issue. When gpt-4o is set, structured output somehow contains an extra layer with "properties" key defined (see screenshot attached). On the other hand, this "properties" key does not exist when 4o-mini is the chosen model.

So when end_script tries to access structured_output.segments, it returns null.

Image
Originally created by @yoshi-1224 on GitHub (Aug 5, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.7.1 ### Cloud or Self Hosted Cloud ### Steps to reproduce 1. Create any workflow with LLM node whose model is set up gpt-4o and structured output schema is defined 2. In the following node (say "End"), refer to the variable defined in the structured output Screenshot for step 1 <img width="433" height="721" alt="Image" src="https://github.com/user-attachments/assets/3d20189d-bdc3-4b4f-801d-af1af8ee0d24" /> Screenshot for step 2 <img width="432" height="432" alt="Image" src="https://github.com/user-attachments/assets/c7bb9aaf-4159-4d10-8e68-c85c741b5f84" /> ### ✔️ Expected Behavior End node will output the value inside the variable correctly. In this case, easy_script contains segments ### ❌ Actual Behavior easy_script is null when model is gpt-4o. However, when 4o-mini is used, it works. I think I know the issue. When gpt-4o is set, structured output somehow contains an extra layer with "properties" key defined (see screenshot attached). On the other hand, this "properties" key does not exist when 4o-mini is the chosen model. So when end_script tries to access structured_output.segments, it returns null. <img width="698" height="142" alt="Image" src="https://github.com/user-attachments/assets/cd3ca57f-6259-40fd-82b5-fdc948dfe88d" />
yindo added the 🐞 bug label 2026-02-21 19:23:58 -05:00
yindo closed this issue 2026-02-21 19:23:58 -05:00
yindo commented 2026-02-21 19:23:58 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Aug 5, 2025):

Hi @yoshi-1224! I'm Dosu and I’m helping the dify team.

This happens because Dify handles structured output differently for models with native JSON schema support (like gpt-4o) versus those that use prompt-based extraction (like 4o-mini). For gpt-4o, Dify wraps your schema in an extra layer with a schema key, so the actual data is nested deeper. That means if you try to access structured_output.segments, it returns null—your data is actually at structured_output.schema.segments (or similar, depending on your schema) [code reference].

To work around this, update your downstream node to reference the correct nested path (e.g., structured_output.schema.segments). This difference is architectural and not a bug, and it can affect any model flagged as supporting native structured output in Dify [issue].

There’s ongoing work to improve structured output compatibility and variable handling in Dify, so this may get smoother in future releases [PR #23002]. If you need help referencing the nested variable in your workflow, let me know your schema and I can suggest the exact path.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Aug 5, 2025): <!-- Greeting --> Hi @yoshi-1224! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> This happens because Dify handles structured output differently for models with native JSON schema support (like gpt-4o) versus those that use prompt-based extraction (like 4o-mini). For gpt-4o, Dify wraps your schema in an extra layer with a `schema` key, so the actual data is nested deeper. That means if you try to access `structured_output.segments`, it returns null—your data is actually at `structured_output.schema.segments` (or similar, depending on your schema) [[code reference](https://github.com/langgenius/dify/blob/2575eaf1d6891d69133974fb8c7a2c7931385244/api/core/llm_generator/output_parser/structured_output.py)]. To work around this, update your downstream node to reference the correct nested path (e.g., `structured_output.schema.segments`). This difference is architectural and not a bug, and it can affect any model flagged as supporting native structured output in Dify [[issue](https://github.com/langgenius/dify/issues/21767)]. There’s ongoing work to improve structured output compatibility and variable handling in Dify, so this may get smoother in future releases [[PR #23002](https://github.com/langgenius/dify/pull/23002)]. If you need help referencing the nested variable in your workflow, let me know your schema and I can suggest the exact path. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/8cf272de-12d7-4144-8677-aebf8935c218?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/8cf272de-12d7-4144-8677-aebf8935c218?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/8cf272de-12d7-4144-8677-aebf8935c218?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/8cf272de-12d7-4144-8677-aebf8935c218?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/8cf272de-12d7-4144-8677-aebf8935c218?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/8cf272de-12d7-4144-8677-aebf8935c218?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/8cf272de-12d7-4144-8677-aebf8935c218?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/23458)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#15917
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?