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

[PR #32089] fix: metadata batch edit silently fails by swallowing exceptions #33543

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

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

State: closed
Merged: No

Summary

  • Fixes a bug where batch metadata edits appeared to succeed but silently failed, with no changes actually persisted.
  • The update_documents_metadata method caught all exceptions with a bare except clause and only logged them, always returning {"result": "success"} to the API caller regardless of whether the update actually succeeded.
  • Additionally, the method had two separate db.session.commit() calls which could leave the database in an inconsistent state if the second commit failed (doc_metadata JSON updated but metadata bindings not created/updated).

Root Cause

In MetadataService.update_documents_metadata():

try:
    # ... update doc_metadata ...
    db.session.commit()       # <-- first commit: doc_metadata updated
    # ... update bindings ...
    db.session.commit()       # <-- second commit: bindings updated
except Exception:
    logger.exception("Update documents metadata failed")  # silently swallowed!

Any exception (lock conflicts, DB errors, validation errors) was silently caught and logged. The API endpoint always returned 200 success, and the frontend showed a success toast even though nothing was saved.

Fix

  1. Consolidate into a single db.session.commit() for atomicity -- both doc_metadata and bindings are committed together or not at all
  2. Add db.session.rollback() on exception to clean up the session state
  3. Re-raise the exception so the API endpoint returns a proper error response to the frontend

Test plan

  • Ruff linting passes
  • Verify batch metadata edit now shows error when backend fails
  • Verify batch metadata edit succeeds when backend processes correctly

Closes #31964

**Original Pull Request:** https://github.com/langgenius/dify/pull/32089 **State:** closed **Merged:** No --- ## Summary - Fixes a bug where batch metadata edits appeared to succeed but silently failed, with no changes actually persisted. - The `update_documents_metadata` method caught all exceptions with a bare `except` clause and only logged them, always returning `{"result": "success"}` to the API caller regardless of whether the update actually succeeded. - Additionally, the method had two separate `db.session.commit()` calls which could leave the database in an inconsistent state if the second commit failed (doc_metadata JSON updated but metadata bindings not created/updated). ## Root Cause In `MetadataService.update_documents_metadata()`: ```python try: # ... update doc_metadata ... db.session.commit() # <-- first commit: doc_metadata updated # ... update bindings ... db.session.commit() # <-- second commit: bindings updated except Exception: logger.exception("Update documents metadata failed") # silently swallowed! ``` Any exception (lock conflicts, DB errors, validation errors) was silently caught and logged. The API endpoint always returned 200 success, and the frontend showed a success toast even though nothing was saved. ## Fix 1. **Consolidate into a single `db.session.commit()`** for atomicity -- both doc_metadata and bindings are committed together or not at all 2. **Add `db.session.rollback()` on exception** to clean up the session state 3. **Re-raise the exception** so the API endpoint returns a proper error response to the frontend ## Test plan - [x] Ruff linting passes - [ ] Verify batch metadata edit now shows error when backend fails - [ ] Verify batch metadata edit succeeds when backend processes correctly Closes #31964
yindo added the pull-request label 2026-02-21 20:53:28 -05:00
yindo closed this issue 2026-02-21 20:53:28 -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#33543
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?