This is a problem I've (knowingly) introduced when implementing the cache. The reason is that it just takes quite long to generate the asset table's contents. So refreshing the entire table after contents deleting a single row makes no sense.
@okurz Did you check whether the asset has been removed from the database table and from the file system? If that works it is sufficient in my opinion. We could add a note so people are aware of that limitation. It should also be possible to re-trigger the cache generation. This should refresh the view.
If we really wanted to fix this we needed to have all information in the database (without the need to compute data on the fly). At the time I thought it wasn't worth the effort. Note that removing an asset also has an impact on the size compution and on the list under the table. That would go "out-of-sync" when one just deletes the row from the database. So making this work altogether is quite a task and again I'm not sure whether it is worth the effort.
@Xiaojing_liu To answer your concrete questions:
The asset had been removed from the database and the asset file (e.g xxx.iso or xxx.qcow2) had also been removed.
That's good and actually good enough in my opinion.
If my understanding is correct, the assets data shown in the table is come form the asset cache file, but after removing assets, the asset cache file is not refreshed.
That's correct.
So, should the cache file be refreshed after removing assets by clicking the 'x' picture?
No, it would take annoyingly long to refresh the entire cache.