Showing results for 
Search instead for 
Did you mean: 

Recovery from failed plugin update

Cisco Employee
Cisco Employee

I see a fairly infrequent but definitely recurrent issue where the plugin update fails, leaving a a corrupt/partial plugin file that has now overwritten the decent (previous) one.   The means the CS client application cannot be restarted without manual intervention to either copy a manually downloaded plugin into place or modify the property file to point to an OK but older version to get the thing back up and running.

This seems to be an area that would benefit from some minor enhancements, for example:

  1. Have built-in (non-plugin based) code that will re-bootstrap the whole plugin download and update if there isn't a working one present.
  2. Have a specific recovery plugin that isn't auto-updated and potentially corrupted.
  3. Look for an older valid plugin in the same directory and use that.
  4. (Related to 3)  On updates, rename/save the current plugin to a backup version rather than overwrite it and use that for recovery on restart if the update has failed.

Or, are you assuming that the client application itself will trap the failed update and implement recovery action to locate a backup plugin?

What is done in the out-the-box CS connectors to work around this type of failure?  What action has to be taken to recover from such a failure, given the concealed nature of the install/activation?   Clearly, the need for manual intervention has a potentially serious impact.


1 Reply 1


This is addressed in our upcoming SDK 2.0 version, a newer static interface to better manage with dependencies and updates. SDK 2.0 will be released close to 11.5 release, probably sooner.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: