Health check not waiting for selenium hub to be up

[kapilag]

trafficstars

First of all thanks for this service. disclaimer: I am very new to webdriverio and javascript.

Issue: docker service doesn't wait for hub to be up when using "zalenium" Details I am using zalenium docker images to start hub/node, and using health property for docker-service. Since zalenium take sometime to start hub and register node , docker service is not waiting for it to be up reason for this behaviour is, health end point doesnot wait for the service to return 200OK which is kind of make sense as well after reading fetch documentation , but right now I am stuck with this problem.

Fix: Ideal fix: would be to take a call back in health options and wait for it to be complete. Quick fix: would be to implement checkStatus function in health , similar to this

If you agree this is issue and should be fixed, I can take first stab at fixing this.

[stsvilik]

@kapilag Option healthCheck is designed to be configurable for cases like that. If you feel that Zelenium takes longer to start simply adjust the delay like so:

healthCheck: {
    url: 'http://localhost:4444',
    maxRetries: 3,
    inspectInterval: 1000,
    startDelay: 2000
}

This setup should cover scenario even for Zelenium.

Another thing you want to pay attention to is the way test is written. For example if test is not waiting for a browser to open a url it will run through test before it is ready. Make sure you return promises and or wait for await to complete.

[kapilag]

Yes I have used the same solution mentioned by you as of now , but start delay was something I thought we can get rid off.

Also zalenium gives a status URL, which return status of hub/nod in response body, Which is the correct way of checking whether hub/node is up

Similar functionality can be provided by different services like selenoid or other and call back function should be ideal solution? What do you think?

On Sat, 24 Aug, 2019, 8:25 PM Simon Tsvilik, [email protected] wrote:

@kapilag https://github.com/kapilag Option healthCheck is designed to be configurable for cases like that. If you feel that Zelenium takes longer to start simply adjust the delay like so:

healthCheck: { url: 'http://localhost:4444', maxRetries: 3, inspectInterval: 1000, startDelay: 2000 }

This setup should cover scenario even for Zelenium.

Another thing you want to pay attention to is the way test is written. For example if test is not waiting for a browser to open a url it will run through test before it is ready. Make sure you return promises and or wait for await to complete.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stsvilik/wdio-docker-service/issues/57?email_source=notifications&email_token=AA7ARBRTGP5SUJZJJBDQ6GDQGFDX5A5CNFSM4IPFTJB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CBWEA#issuecomment-524557072, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7ARBT5JKKD3DNRYQK4TGDQGFDX5ANCNFSM4IPFTJBQ .

[stsvilik]

@kapilag Are you suggesting to wait on Docker events for built-in health check monitoring before starting a test? As an alternative to polling for service start using fetch?

[kapilag]

@stsvilik :not really docker events, if you go to zalenium page over here , there is section having status url which is : http://localhost:4444/wd/hub/status Response for this url would:

      "status": 0,
      "value": {
        "ready": true,
        "message": "Hub has capacity",
        "build": {
          "revision": "6e95a6684b",
          "time": "2017-12-01T19:05:32.194Z",
          "version": "3.8.1"
        },
        "os": {
          "arch": "amd64",
          "name": "Linux",
          "version": "4.9.49-moby"
        },
        "java": {
          "version": "1.8.0_151"
        }
      }
    }

So ideally user of docker service would like to wait for "value.ready=true" in case of zalenium, now this can be different for different service. If docker-service provides call backs function which get executed untill condition is true or < timeout, then it is upto user to implement such logic and wait for value.ready=true.

[stsvilik]

@kapilag I think a custom healthecheck function is a doable option, however I'm not sure when I would be able to look into this.

[seanpoulter]

Are we still interested in this feature?

If I understand correctly, we'd want to have healthCheck be a function that returns a Promise that resolves when the service is ready, and rejects when it times out. Based on the example response from Zalenium above and reworking the polling from https://github.com/webdriverio-community/wdio-docker-service/blob/37e7ba717b47aa407f6e8f8d69987c40701aed66/src/utils/docker.js#L140.

I believe that'd be something like:

/**
 * Resolves when Zalenium indicates the service is ready (`value.ready` is `true`).
 * Rejects when the service is not ready before `timeout` milliseconds.
 */
const healthCheck = async ({ interval = 500, timeout = 10_000 }) => {
  const start = Date.now();

  for (let elapsed = 0; elapsed < timeout; elapsed = Date.now() - start) {
    const response = await fetch('http://localhost:4444/wd/hub/status');
    const body = await response.json();
    if (body?.value?.ready === true) {
      return;
    }
    await setTimeoutPromise(interval);
  }

  throw new Error(`Timed out waiting for Zalenium after ${timeout.toLocaleString()} ms`);
};