Fix deployment list

[Mahmoud-Emad]

Description

There is an issue with listing VMs due to the merge of the Caprover PR

Changes

• Keep the worker listed if the user deletes only the leader.
• Remove the 'Manage Workers' button if the listed VM is a worker.
• Remove the 'View Admin Panel' button if the listed VM is a worker.
• Check if the full deployment has a 'leader' instead.
• Fix listing issues in the other solutions.
• Update the mergeCaproverDeployment function.
• Fix an issue with adding a worker on a deployed Caprover leader

Related Issues

• 🐞 [Bug]: VM, Full can't list any deployment  #3542

Tested Scenarios

A list of scenarios tried to match the deliverables

To consider

Preliminary Checks:

• Does it completely address the issue linked?
• What about edge cases?
• Does it meet the specified acceptance criteria?
• Are there any unintended side effects?
• Does the PR adhere to the team's coding conventions, style guides, and best practices?
• Does it integrate well with existing features?
• Does it impact the overall performance of the application?
• Are there any bottlenecks or slowdowns?
• Has it been optimized for efficiency?
• Has it been adequately tested with unit, integration, and end-to-end tests?
• Are there any known defects or issues?
• Is the code well-documented?
• Are changes to documentation reflected in the code?

UI Checks:

• If a UI design is provided/ does it follow it?
• Does every button work?
• Is the data displayed logical? Is it what you expected?
• Does every validation work?
• Does this interface feel intuitive?
• What about slow network? Offline?
• What if the gridproxy/graphql/chain is failing?
• What would a first time user have a hard time navigating here?

Code Quality Checks:

• Code formatted/linted? Are there unused imports? .. etc
• Is there redundant/repeated code?
• Are there conditionals that are always true or always false?
• Can we write this more concisely?
• Can we reuse this code? If yes, where?
• Will the changes be easy to maintain and update in the future?
• Can this code become too complex to understand for other devs?
• Can this code cause future integration problems?

Checklist

• Tests included
• Build pass
• Documentation
• Code format and docstrings
• Screenshots/Video attached (needed for UI changes)

[Mahmoud-Emad]

Tested scenarios

• Listing in the Micro/Full VMs solutions
• Listing a valid Caprover cluster
• Listing an invalid Caprover cluster see the attached image

[Mahmoud-Emad]

Converted to draft due to an issue happened when deleting the instances

[Mahmoud-Emad]

Converted to draft due to an issue happened when deleting the instances

Should be fixed now

Investigation and Solution:

This issue might be due to how Promise.all handles errors versus the sequential for loop. With Promise.all, all deleteDeployment calls are executed concurrently, meaning the delete_machine method might check for the deployment existence before another instance of it finishes deleting. In contrast, a regular for loop executes sequentially, so each deleteDeployment call completes before the next starts, avoiding potential race conditions.

Work Completed:

Prevent a race condition in deployment deletion by switching to sequential execution

• Replaced Promise.all with a .reduce() approach to sequentially await each deleteDeployment and deleteGatewayDeployment call.

[0oM4R]

caprover deployments didn't show up on the deployment list, they were listed but after click on delete they are still on the contracts list,

[samaradel]

I faced the same delete issue again

[0oM4R]

caprover deployments didn't show up on the deployment list, they were listed but after click on delete they are still on the contracts list,

still happening..

also while deleting the cluster it shows 5 chips while i only have 1 leader and 2 workers

will ignore the caprover for now

[0oM4R]

listing deployments works fine.
will reopen caprover issue
and will open new issue to revisit deployment list changes