You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 8, 2022. It is now read-only.
Currently, the global option PluginLoadTimeout is implemented such that we wait till we receive the plugin's response (which is the preamble) or we timeout. There could be cases where we are able to get to the point where we receive the plugin response but the plugin load is still unsuccessful. This requires us to change the implementation of timeout such that we wait until we receive a loaded plugin in plugin_manager.go. So, we need to block until receiving a loaded plugin or timeout expiry.
Similarly, in startPlugin in runner.go, we need to wait until receiving a channel's response which either has an available plugin or error, and then timeout.
Also, PluginLoadTimeout is hardcoded in control/runner.go. This makes it inconsistent with other code paths as the timeout value is being read from config in those. We need to make it more consistent and have all the code paths read the timeout value from the config as opposed to hardcoding the value.
Currently, the global option PluginLoadTimeout is implemented such that we wait till we receive the plugin's response (which is the preamble) or we timeout. There could be cases where we are able to get to the point where we receive the plugin response but the plugin load is still unsuccessful. This requires us to change the implementation of timeout such that we wait until we receive a loaded plugin in plugin_manager.go. So, we need to block until receiving a loaded plugin or timeout expiry.
Similarly, in startPlugin in runner.go, we need to wait until receiving a channel's response which either has an available plugin or error, and then timeout.
Also, PluginLoadTimeout is hardcoded in control/runner.go. This makes it inconsistent with other code paths as the timeout value is being read from config in those. We need to make it more consistent and have all the code paths read the timeout value from the config as opposed to hardcoding the value.