AppManager's command processing and DecApp state management logic

[weiqiushi]

AppManager's command processing and DecApp state management logic

Currently, AppManager's operation of DecApp is implemented by defining a series of AppCmd. These AppCmd are atomized. The important AppCmd at present are

• Install: Download and install DecApp to the default location
• Start: Start a DecApp from the default location
• Stop: Stop an App
• Uninstall: Remove an App from the default location

However, in addition to the above atomic operations, there are some complex operations on App, such as

• Restart: restart a DecApp, whether it is already running or not
• Reinstall: reinstall an installed app with the current version
• Upgrade: Upgrade/downgrade an app to a specified version
• And so on...

In the current implementation, these complex operations are translated into a collection of atomic operations, which are executed in the following order.

• Restart: Stop + Start
• Reinstall/Upgrade: Stop + Uninstall + Inatall + Start
• And so on...

This design was originally intended to facilitate the design of product interactions on the App Management page in the CYFS browser. How to translate complex operations can be easily modified according to interaction requirements.

However, in practice, we found that.

1. in practice, there is no occasion to modify the translation
2. translating complex operations into existing atomic operations will lose some extra information

   Consider the following scenario: upgrading DecApp from version x to version y, but at this time version y is not available for download.
   This operation will be translated as: Stop(x)+Uninstall(x)+Install(y)+Start(y)
   But when the execution fails when it reaches Install(y), DecApp will not fall back to version x at this time, but will stay in the installation failure state. Because the context of Upgrade(x to y) is lost, AppManager treats it as an ordinary installation operation.

The above operation translation problem is also related to the following state recovery problem

How AppManager restores the state of DecApp

Consider the following scenario: AppManager wants to restart a DecApp

1. AppManager translates Restart to Stop + Start
2. AppManager executes Stop, consumes the Stop command, and first sets the DecApp state to Stopping
3. While waiting for the DecApp to stop, AppManager restarts itself
4. When the state of AppManager is restored, we see that DecApp is Stopping. At this time, because the context of Restart is lost, AppManager can only set the DecApp to StopFailed state.
5. The remaining Start command is consumed, but since the DecApp is already in the Failed state, this command is deprecated.
6. A normal DecApp thus enters the wrong state and can only be manually intervened by the user

Similar situation occurs for other operation translations

[weiqiushi]

Translate It To Chinese:

AppManager的命令处理和DecApp状态管理逻辑

当前，AppManager对DecApp的操作，是定义了一系列AppCmd来实现的。这些AppCmd是原子化的。目前重要的AppCmd有：

• Install：下载并安装DecApp到默认位置
• Start：从默认位置启动一个DecApp
• Stop：停止一个App
• Uninstall：从默认位置删除一个App

但是，除了上述的原子操作之外，还存在一些对App的复杂操作，比如：

• Restart: 重启一个DecApp，无论它是否已经在运行
• Reinstall：以当前版本，重新安装一个已安装的App
• Upgrade：将一个App，升级/降级到指定版本
• 等等...

当前的实现中，这些复杂操作，会被翻译成原子操作的集合，顺序去执行：

• Restart: Stop + Start
• Reinstall/Upgrade: Stop + Uninstall + Inatall + Start
• 等等...

这种设计的初衷，是为了方便CYFS浏览器中，App管理页面的产品交互设计。复杂操作如何翻译，是可以根据交互需求，方便的做修改的。

但在实践中，我们发现：

1. 实际上，并没有需要修改翻译的场合
2. 将复杂操作翻译为已有的原子操作，会丢失一些额外的信息

   考虑下列场景：将DecApp从版本x升级到版本y，但此时版本y并不能下载：
   这个操作会被翻译为：Stop(x)+Uninstall(x)+Install(y)+Start(y)
   但当执行到Install(y)时失败，此时DecApp不会回退到版本x，而是停留在安装失败的状态。因为Upgrade(x to y)的上下文已经丢失，AppManager当作一次普通的安装操作去处理

上述的操作翻译问题，也和下边的状态恢复问题有关

AppManager如何恢复DecApp的状态

考虑下列场景：AppManager要重启某个DecApp

1. AppManager将Restart翻译为Stop + Start
2. AppManager执行Stop，消耗了Stop命令，首先将DecApp状态置为Stopping
3. 在等待DecApp停止时，AppManager自身重启了
4. 在AppManager的状态恢复时，看到了DecApp为Stopping状态。此时由于丢失了Restart的上下文，AppManager只能将DecApp置为StopFailed状态
5. 消耗剩下的Start命令，但由于DecApp已经是Failed状态，这个命令被废弃了
6. 一个正常的DecApp就这样进入了错误的状态，只能由用户手工干预

其他的操作翻译，也会出现类似的情况

[weiqiushi]

@glen0125 @lurenpluto @alexsunxl @lizhihongTest

[glen0125]

I think the appropriate approach here is to just have a reasonable design principle and implement it right.
Any complex operation translated into a collection of simple commands is reasonable by design, and if there is a more reasonable solution we can bring it up for discussion.
And this design allows for precise feedback of the current state of the app to and interaction with the upper layers.
At which step any state fails, it would be nice to have a reasonable explanation, feedback to the upper layer, and some way for the upper layer to recover (continue).
I don't see a problem with the few examples you listed, which are common when using some tools.
To upgrade to a new version, it fails to install the new version, there is nothing wrong with the message that the installation failed, right?
After the stop, if the system restarted, then you can directly enter StopFailed, you can also do more complex checks, for example: at startup to determine whether the app is in the stopping state, if so, then check the app state again and then correct back to the correct state. But my suggestion is to just set it to StopFailed and let the user restore it. Less is better than more here. Because the system restarted I think the user will also be aware of, he should not think there is anything wrong with stopping the failure here, as long as you can continue to operate.
The problem here has nothing to do with splitting the compound command into simple commands, right? It's just a matter of how far we have to go to fix the state.