Bugs found in dify orm #20506

Closed
opened 2026-02-21 20:07:44 -05:00 by yindo · 10 comments
Owner

Originally created by @asukaminato0721 on GitHub (Nov 24, 2025).

Originally assigned to: @asukaminato0721 on GitHub.

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

master

Cloud or Self Hosted

Self Hosted (Source)

Steps to reproduce

This records all the bugs I found in Base -> TypeBase.


RecommendedApp(
description: Mapped[dict] = mapped_column(sa.JSON, nullable=False)

But the callee shows the desc is

.add_argument("desc", type=str, location="json")

so one is dict, one is str.

✔️ Expected Behavior

The type matches.

Actual Behavior

not match

Originally created by @asukaminato0721 on GitHub (Nov 24, 2025). Originally assigned to: @asukaminato0721 on GitHub. ### 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 master ### Cloud or Self Hosted Self Hosted (Source) ### Steps to reproduce This records all the bugs I found in Base -> TypeBase. --- ``` RecommendedApp( description: Mapped[dict] = mapped_column(sa.JSON, nullable=False) ``` But the callee shows the desc is ```py .add_argument("desc", type=str, location="json") ``` so one is dict, one is str. ### ✔️ Expected Behavior The type matches. ### ❌ Actual Behavior not match
yindo added the 🐞 bug label 2026-02-21 20:07:44 -05:00
yindo closed this issue 2026-02-21 20:07:44 -05:00
Author
Owner

@asukaminato0721 commented on GitHub (Nov 24, 2025):

also cc @laipz8200

@asukaminato0721 commented on GitHub (Nov 24, 2025): also cc @laipz8200
Author
Owner

@asukaminato0721 commented on GitHub (Nov 24, 2025):

in

DatasetProcessRule(
created_by: Mapped[str] = mapped_column(StringUUID, nullable=False)

but

            # extract
            processing_rule = DatasetProcessRule(
                mode=tmp_processing_rule["mode"], rules=json.dumps(tmp_processing_rule["rules"])
            )

missing a field.

@asukaminato0721 commented on GitHub (Nov 24, 2025): in ``` DatasetProcessRule( created_by: Mapped[str] = mapped_column(StringUUID, nullable=False) ``` but ``` # extract processing_rule = DatasetProcessRule( mode=tmp_processing_rule["mode"], rules=json.dumps(tmp_processing_rule["rules"]) ) ``` missing a field.
Author
Owner

@dosubot[bot] commented on GitHub (Nov 24, 2025):

You're correct—when creating a DatasetProcessRule, the created_by field is required and non-nullable, so it must be provided during instantiation. Omitting created_by (as in your example) will cause an error when the ORM tries to persist the object, since SQLAlchemy expects all non-nullable fields to be set. In production code, created_by is typically set to the account's ID, for example:

DatasetProcessRule(
    dataset_id=dataset.id,
    mode=process_rule.mode,
    rules=process_rule.rules.model_dump_json() if process_rule.rules else None,
    created_by=account.id,
)

You can see the model definition and usage patterns here:
DatasetProcessRule definition
Typical instantiation with required fields

To fix the missing field issue, always include created_by (and any other required fields) when instantiating DatasetProcessRule.

To reply, just mention @dosu.


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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Nov 24, 2025): <!-- Answer --> You're correct—when creating a DatasetProcessRule, the created_by field is required and non-nullable, so it must be provided during instantiation. Omitting created_by (as in your example) will cause an error when the ORM tries to persist the object, since SQLAlchemy expects all non-nullable fields to be set. In production code, created_by is typically set to the account's ID, for example: ```python DatasetProcessRule( dataset_id=dataset.id, mode=process_rule.mode, rules=process_rule.rules.model_dump_json() if process_rule.rules else None, created_by=account.id, ) ``` You can see the model definition and usage patterns here: [DatasetProcessRule definition](https://github.com/langgenius/dify/blob/bcbd3de33647f308385ce998a92980dfb0d00e6b/api/models/dataset.py#L310-L323) [Typical instantiation with required fields](https://github.com/langgenius/dify/blob/bcbd3de33647f308385ce998a92980dfb0d00e6b/api/services/dataset_service.py#L1564-L1581) To fix the missing field issue, always include created_by (and any other required fields) when instantiating DatasetProcessRule. <!-- 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/c970b8cf-7359-4edb-8045-708c9ea5c43c?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c970b8cf-7359-4edb-8045-708c9ea5c43c?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c970b8cf-7359-4edb-8045-708c9ea5c43c?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c970b8cf-7359-4edb-8045-708c9ea5c43c?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c970b8cf-7359-4edb-8045-708c9ea5c43c?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c970b8cf-7359-4edb-8045-708c9ea5c43c?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c970b8cf-7359-4edb-8045-708c9ea5c43c?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=You%27re%20correct%E2%80%94when%20creating%20a%20DatasetProcessRule%2C%20the%20created_by%20field%20is%20required%20and%20non-nullable%2C%20so%20it%20must%20be%20provided%20during%20instantiation.%20Omitting%20created_by%20%28as%20in%20your%20example%29%20will%20cause%20an%20error%20when%20the%20ORM%20tries%20to%20persist%20the%20object%2C%20since%20SQLAlchemy%20expects%20all%20non-nullable%20fields%20to%20be%20set.%20In%20production%20code%2C%20created_by%20is%20typically%20set%20to%20the%20account%27s%20ID%2C%20for%20example%3A%20%0A%0A%60%60%60python%0ADatasetProcessRule%28%0A%20%20%20%20dataset_id%3Ddataset.id%2C%0A%20%20%20%20mode%3Dprocess_rule.mode%2C%0A%20%20%20%20rules%3Dprocess_rule.rules.model_dump_json%28%29%20if%20process_rule.rules%20else%20None%2C%0A%20%20%20%20created_by%3Daccount.id%2C%0A%29%0A%60%60%60%0AYou%20can%20see%20the%20model%20definition%20and%20usage%20patterns%20here%3A%20%20%0A%5BDatasetProcessRule%20definition%5D%28https%3A//github.com/langgenius/dify/blob/bcbd3de33647f308385ce998a92980dfb0d00e6b/api/models/dataset.py%23L310-L323%29%20%20%0A%5BTypical%20instantiation%20with%20required%20fields%5D%28https%3A//github.com/langgenius/dify/blob/bcbd3de33647f308385ce998a92980dfb0d00e6b/api/services/dataset_service.py%23L1564-L1581%29%0A%0ATo%20fix%20the%20missing%20field%20issue%2C%20always%20include%20created_by%20%28and%20any%20other%20required%20fields%29%20when%20instantiating%20DatasetProcessRule.)&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/28574)
Author
Owner

@asukaminato0721 commented on GitHub (Nov 24, 2025):

class Workflow(
    _features: Mapped[str] = mapped_column("features", LongText)

in py side, the field is called _features, in sql side, this called features.

but all other places use features=json.dumps(features),

@asukaminato0721 commented on GitHub (Nov 24, 2025): ``` class Workflow( _features: Mapped[str] = mapped_column("features", LongText) ``` in py side, the field is called `_features`, in sql side, this called `features`. but all other places use `features=json.dumps(features),`
Author
Owner

@asukaminato0721 commented on GitHub (Nov 24, 2025):

@dosu

@asukaminato0721 commented on GitHub (Nov 24, 2025): @dosu
Author
Owner

@dosubot[bot] commented on GitHub (Nov 24, 2025):

The naming difference between _features (Python attribute) and features (SQL column) in the Workflow model is intentional and managed via a property. All code paths assign features as a JSON string—callers use json.dumps before assignment—which matches the model's expectations and avoids type errors. This pattern is consistent throughout the codebase and aligns with other fields in the model, like _environment_variables. There are no unresolved issues or discussions about this approach, and it's working as designed. If you have specific cases where this causes problems or confusion, let me know and I can dig deeper.

For reference, see the model and property implementation here and typical usage in services here.

To reply, just mention @dosu.


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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Nov 24, 2025): <!-- Answer --> The naming difference between _features (Python attribute) and features (SQL column) in the Workflow model is intentional and managed via a property. All code paths assign features as a JSON string—callers use json.dumps before assignment—which matches the model's expectations and avoids type errors. This pattern is consistent throughout the codebase and aligns with other fields in the model, like _environment_variables. There are no unresolved issues or discussions about this approach, and it's working as designed. If you have specific cases where this causes problems or confusion, let me know and I can dig deeper. For reference, see the model and property implementation [here](https://github.com/langgenius/dify/blob/bcbd3de33647f308385ce998a92980dfb0d00e6b/api/models/workflow.py#L146-L309) and typical usage in services [here](https://github.com/langgenius/dify/blob/bcbd3de33647f308385ce998a92980dfb0d00e6b/api/services/workflow_service.py#L202-L249). <!-- 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/36866fec-b488-4954-b59d-0975912086f9?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/36866fec-b488-4954-b59d-0975912086f9?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/36866fec-b488-4954-b59d-0975912086f9?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/36866fec-b488-4954-b59d-0975912086f9?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/36866fec-b488-4954-b59d-0975912086f9?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/36866fec-b488-4954-b59d-0975912086f9?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/36866fec-b488-4954-b59d-0975912086f9?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=The%20naming%20difference%20between%20_features%20%28Python%20attribute%29%20and%20features%20%28SQL%20column%29%20in%20the%20Workflow%20model%20is%20intentional%20and%20managed%20via%20a%20property.%20All%20code%20paths%20assign%20features%20as%20a%20JSON%20string%E2%80%94callers%20use%20json.dumps%20before%20assignment%E2%80%94which%20matches%20the%20model%27s%20expectations%20and%20avoids%20type%20errors.%20This%20pattern%20is%20consistent%20throughout%20the%20codebase%20and%20aligns%20with%20other%20fields%20in%20the%20model%2C%20like%20_environment_variables.%20There%20are%20no%20unresolved%20issues%20or%20discussions%20about%20this%20approach%2C%20and%20it%27s%20working%20as%20designed.%20If%20you%20have%20specific%20cases%20where%20this%20causes%20problems%20or%20confusion%2C%20let%20me%20know%20and%20I%20can%20dig%20deeper.%0A%0AFor%20reference%2C%20see%20the%20model%20and%20property%20implementation%20%5Bhere%5D%28https%3A//github.com/langgenius/dify/blob/bcbd3de33647f308385ce998a92980dfb0d00e6b/api/models/workflow.py%23L146-L309%29%20and%20typical%20usage%20in%20services%20%5Bhere%5D%28https%3A//github.com/langgenius/dify/blob/bcbd3de33647f308385ce998a92980dfb0d00e6b/api/services/workflow_service.py%23L202-L249%29.)&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/28574)
Author
Owner

@asukaminato0721 commented on GitHub (Nov 24, 2025):

@dosu but I am using dataclass, and the type checker will complain about this.

@asukaminato0721 commented on GitHub (Nov 24, 2025): @dosu but I am using dataclass, and the type checker will complain about this.
Author
Owner

@dosubot[bot] commented on GitHub (Nov 24, 2025):

Type checkers complain here because the dataclass field (e.g., _features: Mapped[str]) is a string (the raw JSON), but you often want to work with a dict in Python. Dify handles this by storing the JSON string in the mapped column and exposing a property (like features_dict) that deserializes it for you. This keeps the storage type and the Python interface clean and type-safe for both the ORM and dataclass tooling.

If you want to avoid type checker complaints, keep the mapped column as Mapped[str] (or Mapped[dict] if you use sa.JSON), and use properties for the Pythonic interface. For fields that shouldn't be initialized directly, add init=False to mapped_column, which keeps them out of the dataclass init and helps type checkers understand your intent (example).

Example pattern:

class Workflow(TypeBase):
    _features: Mapped[str] = mapped_column("features", LongText, init=False)

    @property
    def features_dict(self) -> dict[str, Any]:
        return json.loads(self._features) if self._features else {}

    @features_dict.setter
    def features_dict(self, value: dict[str, Any]):
        self._features = json.dumps(value)

This way, you keep type checkers happy and your codebase consistent with Dify's ORM/dataclass integration (see model example, see Account model pattern).

To reply, just mention @dosu.


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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Nov 24, 2025): <!-- Answer --> Type checkers complain here because the dataclass field (e.g., _features: Mapped[str]) is a string (the raw JSON), but you often want to work with a dict in Python. Dify handles this by storing the JSON string in the mapped column and exposing a property (like features_dict) that deserializes it for you. This keeps the storage type and the Python interface clean and type-safe for both the ORM and dataclass tooling. If you want to avoid type checker complaints, keep the mapped column as Mapped[str] (or Mapped[dict] if you use sa.JSON), and use properties for the Pythonic interface. For fields that shouldn't be initialized directly, add init=False to mapped_column, which keeps them out of the dataclass __init__ and helps type checkers understand your intent ([example](https://github.com/langgenius/dify/pull/28519)). Example pattern: ```python class Workflow(TypeBase): _features: Mapped[str] = mapped_column("features", LongText, init=False) @property def features_dict(self) -> dict[str, Any]: return json.loads(self._features) if self._features else {} @features_dict.setter def features_dict(self, value: dict[str, Any]): self._features = json.dumps(value) ``` This way, you keep type checkers happy and your codebase consistent with Dify's ORM/dataclass integration ([see model example](https://github.com/langgenius/dify/blob/bcbd3de33647f308385ce998a92980dfb0d00e6b/api/models/workflow.py#L99-L555), [see Account model pattern](https://github.com/langgenius/dify/blob/bcbd3de33647f308385ce998a92980dfb0d00e6b/api/models/account.py#L87-L266)). <!-- 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/8f206848-8d6d-4eaa-b920-eea404459be8?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/8f206848-8d6d-4eaa-b920-eea404459be8?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/8f206848-8d6d-4eaa-b920-eea404459be8?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/8f206848-8d6d-4eaa-b920-eea404459be8?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/8f206848-8d6d-4eaa-b920-eea404459be8?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/8f206848-8d6d-4eaa-b920-eea404459be8?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/8f206848-8d6d-4eaa-b920-eea404459be8?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=Type%20checkers%20complain%20here%20because%20the%20dataclass%20field%20%28e.g.%2C%20_features%3A%20Mapped%5Bstr%5D%29%20is%20a%20string%20%28the%20raw%20JSON%29%2C%20but%20you%20often%20want%20to%20work%20with%20a%20dict%20in%20Python.%20Dify%20handles%20this%20by%20storing%20the%20JSON%20string%20in%20the%20mapped%20column%20and%20exposing%20a%20property%20%28like%20features_dict%29%20that%20deserializes%20it%20for%20you.%20This%20keeps%20the%20storage%20type%20and%20the%20Python%20interface%20clean%20and%20type-safe%20for%20both%20the%20ORM%20and%20dataclass%20tooling.%0A%0AIf%20you%20want%20to%20avoid%20type%20checker%20complaints%2C%20keep%20the%20mapped%20column%20as%20Mapped%5Bstr%5D%20%28or%20Mapped%5Bdict%5D%20if%20you%20use%20sa.JSON%29%2C%20and%20use%20properties%20for%20the%20Pythonic%20interface.%20For%20fields%20that%20shouldn%27t%20be%20initialized%20directly%2C%20add%20init%3DFalse%20to%20mapped_column%2C%20which%20keeps%20them%20out%20of%20the%20dataclass%20__init__%20and%20helps%20type%20checkers%20understand%20your%20intent%20%28%5Bexample%5D%28https%3A//github.com/langgenius/dify/pull/28519%29%29.%0A%0AExample%20pattern%3A%0A%0A%60%60%60python%0Aclass%20Workflow%28TypeBase%29%3A%0A%20%20%20%20_features%3A%20Mapped%5Bstr%5D%20%3D%20mapped_column%28%22features%22%2C%20LongText%2C%20init%3DFalse%29%0A%0A%20%20%20%20%40property%0A%20%20%20%20def%20features_dict%28self%29%20-%3E%20dict%5Bstr%2C%20Any%5D%3A%0A%20%20%20%20%20%20%20%20return%20json.loads%28self._features%29%20if%20self._features%20else%20%7B%7D%0A%0A%20%20%20%20%40features_dict.setter%0A%20%20%20%20def%20features_dict%28self%2C%20value%3A%20dict%5Bstr%2C%20Any%5D%29%3A%0A%20%20%20%20%20%20%20%20self._features%20%3D%20json.dumps%28value%29%0A%60%60%60%0A%0AThis%20way%2C%20you%20keep%20type%20checkers%20happy%20and%20your%20codebase%20consistent%20with%20Dify%27s%20ORM/dataclass%20integration%20%28%5Bsee%20model%20example%5D%28https%3A//github.com/langgenius/dify/blob/bcbd3de33647f308385ce998a92980dfb0d00e6b/api/models/workflow.py%23L99-L555%29%2C%20%5Bsee%20Account%20model%20pattern%5D%28https%3A//github.com/langgenius/dify/blob/bcbd3de33647f308385ce998a92980dfb0d00e6b/api/models/account.py%23L87-L266%29%29.)&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/28574)
Author
Owner

@laipz8200 commented on GitHub (Dec 14, 2025):

In order to ensure the compatibility of the database structure across various different databases, we generally avoid using advanced formats like JSON as much as possible and expect to convert it into regular strings.
For the fields that already existed in the past, I recommend using the method mentioned by the robot above to set properties and setter methods to automatically handle this conversion.

@laipz8200 commented on GitHub (Dec 14, 2025): In order to ensure the compatibility of the database structure across various different databases, we generally avoid using advanced formats like JSON as much as possible and expect to convert it into regular strings. For the fields that already existed in the past, I recommend using the method mentioned by the robot above to set properties and setter methods to automatically handle this conversion.
Author
Owner

@dosubot[bot] commented on GitHub (Jan 17, 2026):

Hi, @asukaminato0721. I'm Dosu, and I'm helping the Dify team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported a type mismatch issue where JSON dict fields are stored as strings in Dify ORM, causing type checker complaints.
  • The design intentionally stores JSON data as strings for cross-database compatibility.
  • Properties with setters provide dict interfaces in Python, handling naming differences between attributes and SQL columns.
  • Using init=False on mapped_column is recommended to satisfy type checkers.
  • I confirmed and explained this approach along with a maintainer.

Next Steps:

  • Please confirm if this issue is still relevant with the latest version of Dify by commenting here.
  • Otherwise, this issue will be automatically closed in 15 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Jan 17, 2026): Hi, @asukaminato0721. I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported a type mismatch issue where JSON dict fields are stored as strings in Dify ORM, causing type checker complaints. - The design intentionally stores JSON data as strings for cross-database compatibility. - Properties with setters provide dict interfaces in Python, handling naming differences between attributes and SQL columns. - Using `init=False` on `mapped_column` is recommended to satisfy type checkers. - I confirmed and explained this approach along with a maintainer. **Next Steps:** - Please confirm if this issue is still relevant with the latest version of Dify by commenting here. - Otherwise, this issue will be automatically closed in 15 days. Thank you for your understanding and contribution!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#20506