Closed bodom0015 closed 4 years ago
@craig-willis the second tab in that case was purely to verify both parts of the test:
The refreshing was simply to test the "On Load" behaviors. If we plan to support multiple tabs open in the future, then I agree that evolving the notification-stream
is going to be the easier route there.
Unfortunately, as discussed before, the problem with the "Stop" case is that the API server returns before everything is fully removed. One of the following will be needed on the API side to correct this behavior:
DELETE /instance/:id
request could block (synchronous) until the container cleanup is done - in most cases, this seems to happen relatively quicklyInstanceState.DELETING
- note that in this case we will likely need special handling in the Browse view to hide/ignore such instances, and further handling on the "Run" view to redirect back to browse if the instance state is DELETING
Problem
Present in the Dashboard are a set of helper methods that I refer to as the "instance poller". As the name implies, its job is to poll an instance status and automatically stop once the status matches the target value. This is helpful during instance startup, where we need to poll until the
instance.status
is equal to1
(Running).Previously, the instance poller would activate during the following states:
After PR #517, the instance poller no longer appears to operate. See #531
Approach
Change all methods of launching tales (listed above) to use the new
startTale
helper method. Ensure thatself.get('apiCall').waitForInstance(instance);
is explicitly called every timestartTale
is called.How to Test
Prerequisites: at least on public/read-only Tale to copy (can use LIGO), stop all running Tales, keep Networks tab open in browser Dev Console
Create Tale
Please Wait...
Import Tale
Please Wait...
Launching a Tale from Browse / On Load from Browse
Please Wait...
Copy on Launch from Browse
Please Wait...
Launching a Tale from Run / On Load from Run
Please Wait...
Copy on Launch from Run
Please Wait...