fix:When there are multiple pods, upgrading the plugin can cause a null pointer error in the plugin-daemon.

[gaoyue1989]

This is the final execution directory for the Python plugin. Each time a pod restarts, it reads the plugin from the PLUGIN_STORAGE_LOCAL_ROOT directory and installs it, so there’s no need to place it in a shared directory. However, when multiple pods perform upgrade or other write operations on the plugin simultaneously, it can cause issues with the plugin directory, making the plugin inaccessible.

[BorisPolonsky]

According to the documents from dify-plugin-daemon:

• pluginDaemon depends on a shared cwd directory for running plugins
• Daemon community edition are not designed to be seamlessly scaled out as multiple replicas.

Hardcoding PLUGIN_WORKING_PATH doesn't comply with the document and will break backward compatibility.

You may wish to override PLUGIN_WORKING_PATH with a different directory through pluginDaemon.extraEnv in order not to share cwd over replicas, while using PVC for data persistence.

As an alternative, you may also opt in externalS3 for data persistence of pluginDaemon (available since dify-helm-0.24.0). In this way each replica of pluginDaemon shares no persistent volume. Note that you still need to do the data migration yourself for this approach.

[BorisPolonsky]

This is the final execution directory for the Python plugin. Each time a pod restarts, it reads the plugin from the PLUGIN_STORAGE_LOCAL_ROOT directory and installs it, so there’s no need to place it in a shared directory. However, when multiple pods perform upgrade or other write operations on the plugin simultaneously, it can cause issues with the plugin directory, making the plugin inaccessible.

Thanks for clarifying the plugin-daemon mechanism and sticking with this PR - even with the long hold-up, we landed a much better design. Truly appreciated!