Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-36552

Issues with UI messages in eventing on pause and resume

    XMLWordPrintable

Details

    Description

      While in Eventing for any given function/handler

      • When I hit a Deploy button the UI shows first a status of "undeploy..." and then a final status of "deployed"
      • When I hit a Deploy button the UI shows first a status of "undeploying..." and then a final status of "undeployed"

      There seem to be issues with reporting status in the UI when doing a Pause and Resume:

      • ISSUE: When I hit a Pause button the UI shows first a status of "pausing..." and then a final status of either "undeployed" or "paused" (some sort of race condition) I have seen both status messages.
      • ISSUE: When I hit a Resume button the UI shows first a status of "deploying..." and then a final status of "deployed". For consistency after hitting the Resume button case the UI should first show a status of "resuming..." and then a final status of "deployed" when the resume is complete.

      Attachments

        For Gerrit Dashboard: MB-36552
        # Subject Branch Project Status CR V

        Activity

          jon.strabala Jon Strabala added a comment - - edited

          Seems like the Deploy button also has a race where the incorrect status is shown.

          Sometime when I hit a Deploy button the UI showed a final status of "undeployed" until I refresh the browser (see image A_  and also image B_ after a refresh to correct the GUI display).  Thus I imaging that (some sort of race condition) exists for the Deploy button also.

          Note in the above instance (e.g. with the pictures attached) I had a error in the function I deployed where it called a non-existant function, it did process all mutations and showed the failure.

          I tried to recreate the same sequence but it is intermittent and rarely reproduces.

           

          jon.strabala Jon Strabala added a comment - - edited Seems like the Deploy button also has a race where the incorrect status is shown. Sometime when I hit a Deploy button the UI showed a final status of "undeployed" until I refresh the browser (see image A_  and also image B_ after a refresh to correct the GUI display).  Thus I imaging that (some sort of race condition) exists for the Deploy button also. Note in the above instance (e.g. with the pictures attached) I had a error in the function I deployed where it called a non-existant function, it did process all mutations and showed the failure. I tried to recreate the same sequence but it is intermittent and rarely reproduces.  
          jeelan.poola Jeelan Poola added a comment -

          Moving to CC as refresh of UI solves the inconsistencies. We may still pull this back into Mad-Hatter if other higher priority hard bugs get fixed soon. Labelled the ticket accordingly.

          jeelan.poola Jeelan Poola added a comment - Moving to CC as refresh of UI solves the inconsistencies. We may still pull this back into Mad-Hatter if other higher priority hard bugs get fixed soon. Labelled the ticket accordingly.

          Jon Strabala With all the recent fixes to UI, do you still these issues? I believe the resuming... part is still true.

          jeelan.poola Jeelan Poola added a comment - Jon Strabala With all the recent fixes to UI, do you still these issues? I believe the resuming... part is still true.
          jon.strabala Jon Strabala added a comment -

          I did see one more occurrence of a similar issue this last Monday on a source build (6.5.1 made on Feb 24, 2020) in my testing (I'm talking hours of testting) where it was showing "deployed..." and the UI was incapable of fixing the issue [ this was different form the wacky mixed up buttons as per the images I posted ].

          A REST call however worked to get it unstuck (I did not need to resort to "cbevent -flush") and since it was a 6.5.1 UI I didn't need to hit refresh - I think I only ran the first command below:

          curl -X POST -d '{"deployment_status":false,"processing_status":false}' -s 'http://'${CB_USERNAME}:${CB_PASSWORD}'@localhost:8096/api/v1/functions/<<YOUR_FUNCTION_NAME>>/settings'
          curl -X POST -d '{"deployment_status":true,"processing_status":true}' -s 'http://'${CB_USERNAME}:${CB_PASSWORD}'@localhost:8096/api/v1/functions/<<YOUR_FUNCTION_NAME>>/settings'
           

          jon.strabala Jon Strabala added a comment - I did see one more occurrence of a similar issue this last Monday on a source build (6.5.1 made on Feb 24, 2020) in my testing (I'm talking hours of testting) where it was showing "deployed..." and the UI was incapable of fixing the issue [ this was different form the wacky mixed up buttons as per the images I posted ]. A REST call however worked to get it unstuck (I did not need to resort to "cbevent -flush") and since it was a 6.5.1 UI I didn't need to hit refresh - I think I only ran the first command below: curl -X POST -d '{"deployment_status":false,"processing_status":false}' -s 'http://'${CB_USERNAME}:${CB_PASSWORD}'@localhost:8096/api/v1/functions/<<YOUR_FUNCTION_NAME>>/settings' curl -X POST -d '{"deployment_status":true,"processing_status":true}' -s 'http://'${CB_USERNAME}:${CB_PASSWORD}'@localhost:8096/api/v1/functions/<<YOUR_FUNCTION_NAME>>/settings'  

          Proposing to move to CC.Next to keep the focus on Collections in CC.

          jeelan.poola Jeelan Poola added a comment - Proposing to move to CC.Next to keep the focus on Collections in CC.
          jon.strabala Jon Strabala added a comment -

          If we prematurely indicate that we are paused it is possible that a customer might decide it is safe to perform a rebalance and have a potential hang.  Granted this is a small window of time for this to happen.

          jon.strabala Jon Strabala added a comment - If we prematurely indicate that we are paused it is possible that a customer might decide it is safe to perform a rebalance and have a potential hang.  Granted this is a small window of time for this to happen.

          People

            jeelan.poola Jeelan Poola
            jon.strabala Jon Strabala
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:

              Gerrit Reviews

                There is 1 open Gerrit change

                PagerDuty