If we all agree on making such changes, I would love to be signed to work in such issue.
Thanks

I'm fine, I think it's ok/good at short term

at mid-term/long term we should propagate the changes to the 'backend/model' that will be reflected to the client side because if you open the details view during that time you won't see any 'in-progress' action as suggested by @deboer-tim

Yes. I think we use this issue to correct the individual action enablement within each view (i.e. start action is disabled when object is in 'deleting' state). If you delete and change views quickly then the actions may not be correct, but this would be fixed when we propagate status correctly.

I started to look into it today, and I have a few questions and a suggestion. I would like to hear from you :).

First, it is related to the status of an object.

I see we have status being propagated in many places, and the state is represented as a string with different values like: 'DELETING', 'RUNNING', 'STOPPING', etc.

I would like to suggest and hear your ideas and concerns on having it as an enum.

Such refactor would help us to avoid invalid states and misled flows caused by typos. It seems to be big refactor since the extension API also have status as a string and a refactor could break the current API compatibility.

@benoitf, @deboer-tim : After a quick try, it feels to me that I would like to know more about the mid-term/long-term approach to solve this issue. The one that propagate the changes to the 'backend/model' so the client side can make usage of such information in every component.

Could you please guide me on how to follow the code, so I can find and understand better/easily our server/client architecture?

I appreciate your help :)

FYI @trmendes in typescript you can have custom enum with string

like status : 'DELETING' | 'STARTING' you see a string but you can only choose between 2 values

about backend/frontend model, it's just to have the state being shared between 2 views
but we still need the work to be done on each view.

We added such intermediate state to provide UI feedback but they don't exists on the underlying model (docker or podman engines)
but these intermediate states could be stored in the backend

and about 'backend/model/client' side question, basically instead of updating the state in the local copy of the view, it would update the state globally. so if you open both like 'container list view' and 'container's detail view' you'll get all intermediate steps.

FYI @trmendes in typescript you can have custom enum with string

like status : 'DELETING' | 'STARTING' you see a string but you can only choose between 2 values

about backend/frontend model, it's just to have the state being shared between 2 views but we still need the work to be done on each view.

We added such intermediate state to provide UI feedback but they don't exists on the underlying model (docker or podman engines) but these intermediate states could be stored in the backend

and about 'backend/model/client' side question, basically instead of updating the state in the local copy of the view, it would update the state globally. so if you open both like 'container list view' and 'container's detail view' you'll get all intermediate steps.

Thanks for the reply @benoitf :)