Open issues remain for both asynchronous and synchronous upgrades. One open question is how to handle side effects of buggy software upgrades. For example, in an e-commerce application, the web service software might be responsible for computing the tax on a purchase. While we can revert a software upgrade that has a bug in its tax computation code, we can not automatically correct its tax calculations. Although such corrections are clearly application specific, incorporating an undo facility [2] may ease the application developer's burden.
Several issues specific to synchronous upgrades remain as well. First, it is not clear that reverting to the prior process state on a rollback is always the right choice. Routing table data, for example, is often transient. Thus, if a large period of time elapses between the upgrade and the initiation of the rollback, it may make more sense to restart the old software with a clean state (an empty routing table). Also, if the new application version needs to reflect the volatile state of the earlier application, we may need to log and replay messages delivered between the time that the snapshot is taken, and the time that the new software is ready to handle messages.