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 #25329] feat: initialize trigger status at application level to prevent canvas refresh state issues #31013

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

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

State: closed
Merged: Yes

Summary

This PR fixes the trigger status display issue where canvas trigger nodes would show incorrect "disabled" state after page refresh, requiring users to manually open the app overview modal to see the correct status.

Problem:

  • Page refresh → Canvas renders with empty Zustand store → Trigger nodes default to "disabled"
  • Only after opening overview modal would TriggerCard component call API and sync correct status

Solution:

  • Initialize trigger status at WorkflowApp application level using useAppTriggers
  • Leverage React Query caching to prevent duplicate API calls
  • Maintain backward compatibility with existing TriggerCard functionality

Key Changes

  1. Enhanced useAppTriggers (web/service/use-tools.ts):

    • Added optional options parameter for React Query configuration
    • Maintains backward compatibility - all existing calls work unchanged

  2. Application-level initialization (web/app/components/workflow-app/index.tsx):

    • Added trigger status initialization in WorkflowApp component
    • Uses 5-minute cache strategy to optimize performance
    • Syncs status to Zustand store on component mount

Architecture Benefits

✅ Single Source of Truth: All components read from same Zustand store
✅ Performance Optimized: React Query cache prevents duplicate API calls
✅ Backward Compatible: Zero breaking changes to existing code
✅ Immediate Status Display: Canvas shows correct status on page load

Data Flow

Before:

Page refresh → Canvas shows default "disabled" → User opens modal → API call → Status sync

After:

Page refresh → WorkflowApp calls API → Immediate status sync → Canvas shows correct status
TriggerCard → Uses cached data → No duplicate API calls

Testing

  • ✅ All existing tests pass (26/26 tests, 100% coverage)
  • ✅ ESLint checks pass
  • ✅ TypeScript compilation successful
  • ✅ Backward compatibility verified

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/25329 **State:** closed **Merged:** Yes --- ## Summary This PR fixes the trigger status display issue where canvas trigger nodes would show incorrect "disabled" state after page refresh, requiring users to manually open the app overview modal to see the correct status. **Problem**: - Page refresh → Canvas renders with empty Zustand store → Trigger nodes default to "disabled" - Only after opening overview modal would TriggerCard component call API and sync correct status **Solution**: - Initialize trigger status at WorkflowApp application level using `useAppTriggers` - Leverage React Query caching to prevent duplicate API calls - Maintain backward compatibility with existing TriggerCard functionality ## Key Changes 1. **Enhanced `useAppTriggers`** (`web/service/use-tools.ts`): - Added optional `options` parameter for React Query configuration - Maintains backward compatibility - all existing calls work unchanged 2. **Application-level initialization** (`web/app/components/workflow-app/index.tsx`): - Added trigger status initialization in WorkflowApp component - Uses 5-minute cache strategy to optimize performance - Syncs status to Zustand store on component mount ## Architecture Benefits ✅ **Single Source of Truth**: All components read from same Zustand store ✅ **Performance Optimized**: React Query cache prevents duplicate API calls ✅ **Backward Compatible**: Zero breaking changes to existing code ✅ **Immediate Status Display**: Canvas shows correct status on page load ## Data Flow **Before**: ``` Page refresh → Canvas shows default "disabled" → User opens modal → API call → Status sync ``` **After**: ``` Page refresh → WorkflowApp calls API → Immediate status sync → Canvas shows correct status TriggerCard → Uses cached data → No duplicate API calls ``` ## Testing - ✅ All existing tests pass (26/26 tests, 100% coverage) - ✅ ESLint checks pass - ✅ TypeScript compilation successful - ✅ Backward compatibility verified ## Checklist - [x] 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:48:39 -05:00
yindo closed this issue 2026-02-21 20:48:39 -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#31013
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?