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

[PR #23133] fix: metadata API nullable validation consistency issue #30176

New Issue
Closed
opened 2026-02-21 20:46:59 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 20:46:59 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/langgenius/dify/pull/23133

State: closed
Merged: Yes

Fix metadata API nullable validation consistency issue

Fixes #23132

Summary

This PR fixes a critical bug in metadata API parameter validation where the API layer incorrectly accepted null values (nullable=True) while the business logic layer expected non-null values, causing TypeError: object of type 'NoneType' has no len() crashes.

Changes Made

  • Changed nullable=True to nullable=False for required metadata fields in 4 API endpoints
  • Ensured consistency across all validation layers (API, Pydantic, business logic, database)
  • Added comprehensive test coverage with 15 test cases covering all validation scenarios

Fixed endpoints:

  • POST /console/api/datasets/{id}/metadata (type, name fields)
  • PATCH /console/api/datasets/{id}/metadata/{id} (name field)
  • POST /v1/datasets/{id}/metadata (type, name fields)
  • PATCH /v1/datasets/{id}/metadata/{id} (name field)
  • POST /console/api/datasets/{id}/documents/metadata (operation_data field)
  • POST /v1/datasets/{id}/documents/metadata (operation_data field)

Root Cause

The bug occurred because:

  1. API Layer: nullable=True allowed null values to pass validation
  2. Business Logic: Direct len() calls expected non-null values
  3. Database: nullable=False constraints rejected null values
  4. Pydantic: Required fields expected non-null values

This inconsistency caused the API to accept null requests but crash during processing.

Impact

  • Before: API crashes with TypeError when null values are sent
  • After: API properly rejects null values with clear 400 Bad Request error
  • Compatibility: No impact on valid requests, only improves error handling

Screenshots

Before After
TypeError crash on null values Clean 400 Bad Request response

Checklist

  • This change requires a documentation update, included: Dify Document
  • I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!)
  • I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
  • I've updated the documentation accordingly.
  • I ran dev/reformat(backend) and cd web && npx lint-staged(frontend) to appease the lint gods
**Original Pull Request:** https://github.com/langgenius/dify/pull/23133 **State:** closed **Merged:** Yes --- # Fix metadata API nullable validation consistency issue Fixes #23132 ## Summary This PR fixes a critical bug in metadata API parameter validation where the API layer incorrectly accepted null values (`nullable=True`) while the business logic layer expected non-null values, causing `TypeError: object of type 'NoneType' has no len()` crashes. ### Changes Made - Changed `nullable=True` to `nullable=False` for required metadata fields in 4 API endpoints - Ensured consistency across all validation layers (API, Pydantic, business logic, database) - Added comprehensive test coverage with 15 test cases covering all validation scenarios Fixed endpoints: - POST /console/api/datasets/{id}/metadata (type, name fields) - PATCH /console/api/datasets/{id}/metadata/{id} (name field) - POST /v1/datasets/{id}/metadata (type, name fields) - PATCH /v1/datasets/{id}/metadata/{id} (name field) - POST /console/api/datasets/{id}/documents/metadata (operation_data field) - POST /v1/datasets/{id}/documents/metadata (operation_data field) ### Root Cause The bug occurred because: 1. **API Layer**: `nullable=True` allowed null values to pass validation 2. **Business Logic**: Direct `len()` calls expected non-null values 3. **Database**: `nullable=False` constraints rejected null values 4. **Pydantic**: Required fields expected non-null values This inconsistency caused the API to accept null requests but crash during processing. ### Impact - **Before**: API crashes with TypeError when null values are sent - **After**: API properly rejects null values with clear 400 Bad Request error - **Compatibility**: No impact on valid requests, only improves error handling ## Screenshots | Before | After | |--------|-------| | TypeError crash on null values | Clean 400 Bad Request response | ## Checklist - [ ] This change requires a documentation update, included: [Dify Document](https://github.com/langgenius/dify-docs) - [x] I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!) - [x] I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change. - [x] I've updated the documentation accordingly. - [x] I ran `dev/reformat`(backend) and `cd web && npx lint-staged`(frontend) to appease the lint gods
yindo added the pull-request label 2026-02-21 20:46:59 -05:00
yindo closed this issue 2026-02-21 20:46:59 -05:00
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 pull-request
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#30176
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?