Principle:Langgenius Dify Plugin Lifecycle Management

Knowledge Sources	Dify
Domains	Plugin_System, Marketplace, Frontend
Last Updated	2026-02-12 00:00 GMT

Overview

Description

Plugin Lifecycle Management governs the post-installation phases of a plugin's existence within a Dify workspace: task monitoring, status verification, and uninstallation. The principle establishes an asynchronous task pipeline where every installation or upgrade operation produces a trackable task, and the frontend polls for task completion before refreshing the plugin list. Uninstallation is treated as a terminal lifecycle event that removes the plugin from the workspace and cleans up associated resources.

The lifecycle model recognizes three task states:

• Running -- The backend is actively processing the installation or upgrade.
• Success -- The operation completed without errors.
• Failed -- The operation encountered an error; the plugin may be partially installed or in an inconsistent state.

The frontend implements automatic polling that continues at 5-second intervals as long as any task is in a non-terminal state, and stops polling once all tasks reach success or failure. Upon completion, the plugin list is automatically refreshed to reflect the new state.

Usage

Plugin Lifecycle Management is used in the following scenarios:

• Post-installation monitoring -- After initiating a plugin install, the UI calls fetchPluginTasks to retrieve all active tasks and polls via checkTaskStatus until the task reaches a terminal state.
• Batch task management -- The task list endpoint returns all tasks for the workspace with pagination, allowing the UI to display a progress panel showing all in-flight installations.
• Uninstallation -- When a user removes a plugin, uninstallPlugin is called with the plugin_installation_id, which triggers backend cleanup and returns an UninstallPluginResponse.
• Task cleanup -- Completed or failed tasks can be cleared individually or in bulk to keep the task panel clean.

Theoretical Basis

Plugin Lifecycle Management applies the following architectural patterns:

• State machine -- Each task follows a deterministic state machine: running -> success | failed. The frontend uses this state machine to decide polling behavior (continue if any task is running, stop otherwise), UI presentation (spinner vs. checkmark vs. error icon), and side effects (refresh plugin list on success).
• Polling with backoff -- The 5-second polling interval balances responsiveness against server load. The refetchInterval callback in TanStack Query implements conditional polling by returning false when all tasks are terminal, cleanly stopping the interval.
• Event-driven side effects -- The useEffect hook monitors the isRefetching flag and triggers a plugin list refresh when all tasks transition to terminal state. This follows the Observer pattern where the task query's state changes trigger downstream effects.
• Graceful degradation -- Failed tasks do not prevent the UI from functioning. The system distinguishes between "all failed" (no refresh needed) and "some succeeded" (refresh needed) to avoid unnecessary network requests.

Related Pages

• Implementation:Langgenius_Dify_UninstallPlugin