@Dor-bl ten minutes seems crazy. Is that in-line with the other clients?

@Dor-bl ten minutes seems crazy. Is that in-line with the other clients?

Yes it is. Sometimes the startup phase for mobile sessions can take quite lot of time. For example, to boot an iOS simulator on a slow CI node.

Also, the server and drivers usually limit command timings as well, for example via newCommandTimeout, proxy timeout, etc, which means killing the client connection due to read timeout must be used as a last resort. In most of cases such timeout would mean a bug or a missing timeout handler at the server side.

I wondered if it would be nice to have a troubleshooting and add this time thing in our test code as an example rather than overriding the existing one in selenium to avoid unexpected modification in the parent (selenium) side. Just a personal preference.

I wondered if it would be nice to have a troubleshooting and add this time thing in our test code as an example rather than overriding the existing one in selenium to avoid unexpected modification in the parent (selenium) side. Just a personal preference.

You mean part of the Wiki? Because I don't think most users look in the test code.

Yea, this is not strong opinion for the default value itself though.

When we override the value, probably it would be nice to address it in somewhere as well, docstring or wiki? in this dotnet client case. How to modify the timeout in Wiki also should help (as a general documentation thing)

Btw, the commit prefix could be feat. I saw some users had error handling for client side read timeout as well (real devices) to fail fast, so modifying the default value as a patch could change their behavior.

Yea, this is not strong opinion for the default value itself though.

When we override the value, probably it would be nice to address it in somewhere as well, docstring or wiki? in this dotnet client case. How to modify the timeout in Wiki also should help (as a general documentation thing)

Btw, the commit prefix could be feat. I saw some users had error handling for client side read timeout as well (real devices) to fail fast, so modifying the default value as a patch could change their behavior.

@KazuCocoa, Let me know what you think.
https://github.com/appium/dotnet-client/wiki/Troubleshooting#defaultcommandtimeout-field
@mykola-mokhnach, we need to decide if we stay with the Wiki for now and abandon this PR.

we need to decide if we stay with the Wiki for now and abandon this PR.

I don't want to abandon anything. The change makes sense and does fix potential user issues