Feature Request/ Implementation question| hooking driver creation method

[daniel4x]

Feature Request

I'm looking for a guidelines or help implementing retry mechanism for driver creation.
It's really useful and important for testing remote real devices while retrieve one from a pool of devices.

• Reasons for adopting new feature:
  Remote testing could fail sometimes when trying to retrieve a device because the device already in use or unavailable.
  I would like to prevent this by retry in X sec later or by getting a different device.

• Is this a breaking change? (How will this affect existing functionality)
  Not sure.

[NickTomlin]

Could you flesh out what this might look like with some pseudocode? I'm not familiar with remote device testing

[wswebcreation]

Hi @NickTomlin,

What @daniel4x means is the following. Some cloudproviders don't have automatic queueing like Sauce Labs has. For example, you request 10 instances of Chrome, you only have 5, so 5 are queued.

Cloudproviders like for example Perfecto (who has physical devices and browsers) can't queue. They will give back a "error"-message saying that the driver could not be created because they are (all) busy / in use.

In protractor we can't "hook" onto the instantiation of the driver with (get)multi-capabilities. It would be nice that the "error"/"info"-message could be processed with a custom retryscript with some kind of hook or something, like this:

// calling with
multicapabilities:[{
        browserName:chrome
    }, {
        browserName: firefox
}],

// when error message of driver
onDriverError: (message){
    // process the message and trigger the driver to start again for x times
    // this can be done by the script
    // user is responsible of handling the amount of retries and so on
}

Hope this makes is more clear.

Grtz

Wim

[wswebcreation]

Hi @NickTomlin

Did you had time to check this?

[NickTomlin]

I think this seems like a valid use case; I personally won't be able to get to it but i'd welcome a PR.

I'm trying to think of the best way to handle this, do you have an example integration with perfecto? It seems like it might be something that best fits into an additional method for a driver provider that could negotiate this on behalf of the user (I'm open to exposing this via the root config if necessary as well).

[wswebcreation]

Tnx @NickTomlin

@daniel4x will look at it and create a PR

[NickTomlin]

@wswebcreation sure! Feel free to use this thread as a place to discuss options. Thanks!

[daniel4x]

Hi @NickTomlin,
@wswebcreation and I came up with an idea for implementation of this feature.
It requires from us to extend the driver creation logic and enable the driver creation async.

The selection between the different driver creation methods will be controlled from the Protractor configuration file. The actual creation logic will be extracted to a separate method that will be used for both scenarios (For preventing code duplication).

In addition to the above, we would like to add Perfecto as a connection partner, in order to provide perfecto users out of the box retry functionality which described before and some additional Perfecto functionalities such as connection to Perfecto reports.

Thanks!

[wswebcreation]

@NickTomlin
Did you had some time for the questions of @daniel4x ?

Tnx in advance

[NickTomlin]

@wswebcreation @daniel4x

Sounds great! Do you have branch with this I could look at? Or do you mind showing some code examples?

I think doing this in two parts would be excellent:

1. Pull request driver creation logic
2. Pull request Perfecto driver

Let me know if there's any additional questions. Thanks!

[wswebcreation]

@NickTomlin

Tnx for the reply, we'll start working on it and keep you updated

[daniel4x]

@NickTomlin Hey,

Please see the following pull request: #4166
Added a async driver creation & retry mechanism.