I've been trying to run automated tests with Appium, they are already running in physical devices, but I get the error: [WD Proxy] Got an unexpected response: {"value":{"error":"session not created","message":"'capabilities' is mandatory to create a new session"}
I've gone through the configuration guide and the webDriverAgent seems to be running correctly in the device, when I make a request to the webdriveragent running on the device I get the response:
[WD Proxy] Determined that the downstream protocol for proxy is W3C
[XCUITest] WebDriverAgent information:
[XCUITest] {
[XCUITest] "message": "WebDriverAgent is ready to accept commands",
[XCUITest] "state": "success",
However, when Appium makes the request to create a new WDA session, receives the following response:
[WD Proxy] Got an unexpected response: {"value":{"error":"session not created","message":"'capabilities' is mandatory to create a new session"},"sessionId":"595F87C8-0564-4B75-94B4-7D67BA0AF382"}
Using these capabilities
'app': app,
'bundleId' : bundle_id,
'platformName': platform_name,
'automationName': automation_name,
'platformVersion': platform_version,
'deviceName': device_name,
'udid': udid,
'xcodeOrgId': xcode_org_id,
'xcodeSigningId': xcode_signing_id,
'newCommandTimeout': new_command_timeout,
'updatedWDABundleId': updated_WDA_Bundle_Id,
'agentPath': "/usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgent.xcodeproj",
'bootstrapPath': "/usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent"
Is there anything else I might be missing?
Not sure if these capabilities are actually required:
'updatedWDABundleId': updated_WDA_Bundle_Id,
'agentPath': "/usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgent.xcodeproj",
'bootstrapPath': "/usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent"
try removing them, also in my tests i have noticed that it is necessary to restart the appium server everytime you switch from real device to simulator.
Hope it helps
Related
Currently, we are trying to setup neutron for our cloud server. Since everyone is new to this, we are struggling a bit. When we entered this command:
openstack network create --share --external \
--provider-physical-network provider \
--provider-network-type flat provider
And it throws this error:
Error while executing command: HttpException: 503, The Keystone service is temporarily unavailable.: 503 Service Unavailable: The server is currently unavailable. Please try again at a later time.
We are following openstack docs guide to a T.
Does anyone know what causes this error and how to fix it?
Thanks.
I fixed it, it was a problem with MariaDB. When we updated it from 10.1 to 10.3, I couldn't access my DB, so when I fixed that error it works now.
We are using openresty and the lua-resty-auto-ssl package to generate certificates from Lets Encrypt but lately the server keeps falling over. Im guessing its triggered when a certificate trys to auto renew as generating a certificate for first time works fine ... the error we are seeing is
2019/05/12 08:25:24 [error] 2623#2623: *1024227 lua entry thread aborted: runtime error: ...sty/luajit/share/lua/5.1/resty/auto-ssl/servers/hook.lua:40: assertion failed!
stack traceback:
coroutine 0:
[C]: in function 'assert'
...sty/luajit/share/lua/5.1/resty/auto-ssl/servers/hook.lua:40: in function 'server'
.../local/openresty/luajit/share/lua/5.1/resty/auto-ssl.lua:99: in function 'hook_server'
content_by_lua(nginx.conf:194):2: in function <content_by_lua(nginx.conf:194):1>, client: 127.0.0.1, server: , request: "POST /deploy-cert HTTP/1.1", host: "127.0.0.1:8999"
From what I can see in the error it is failing to assert something when trying to deploy the cert which could be any of 4 things
assert(params["domain"])
assert(params["fullchain"])
assert(params["privkey"])
assert(params["expiry"])
Im a bit stuck to what I can do, its no good having the server dropping out on use. Thats the last error thats reported before the server goes offline so im guessing thats the cause? but not 100% sure.
Is there anywhere I can look to find out more information what causes the crash. Im new to nginx/openresty so fumbling my round a bit. Has anyone come across a similar issue?
Wrap it all in a function and call it with pcall or xpcall and add some logic to deal with the error.
I have installed intern on my local machine (192.168.1.50) and want to use the QT Browser webdriver on a remote machine (192.168.1.76). I've changed the intern.js and added the correct hostname as shown beneath:
tunnelOptions: {
hostname: '192.168.1.207:9517'
},
The qt browser is called as well:
environments: [
{ browserName: 'QTBrowser', version: '5.4' , platform: [ 'LINUX' ] }
],
Tunnel is set to NullTunnel.
When executing the tests, following error is shown
C:\intern-tutorial>intern-runner config=tests/intern.js Listening on 0.0.0.0:9000 Tunnel started Suite QTBrowser 5.4 on LINUX FAILED Error: [POST http://192.168.1.207:9517/wd/hub/session] connect ETIMEDOUT
192.168.1.207:4444 at Server.createSession at
at retry
at
at
runCallbacks
at at run
at
at
nextTickCallbackWith0Args at process._tickCallback
TOTAL: tested 0 platforms, 0/0 tests failed; fatal error occurred
Error: Run failed due to one or more suite errors at
emitLocalCoverage
at
finishSuite
at at
at
runCallbacks
at at run
at
at
nextTickCallbackWith0Args at process._tickCallback
I am able to access the remote webdriver myself via the browser using url http://192.168.1.76:9517/status
So the connection is correct, but intern does add the /wd/hub/session which actually isn't needed.
How can I get my intern from not doing this?
You can get past the 'wd/hub' issue by setting pathname on in the tunnel options:
tunnelOptions: {
pathname: '/',
hostname: '192.168.1.207',
port: 9517
}
However, there are currently a couple of incompatibilities between Intern and QtWebDriver. One is that QtWebDriver requires that headers use a specific capitalization scheme, like 'Content-Type'. However, the library Intern uses to handle its requests currently normalizes header names to lowercase. This should be fine, because headers are supposed to be case insensitive, but not everything follows the standard.
Another problem is that, unlike most other WebDriver implementations, QtWebDriver responds to a session creation call with a 303 response rather than a 200, and the redirect address is relative. While that should be fine, the version of the Leadfoot library used by Intern doesn't properly follow relative redirect addresses.
These issues should be fixed in a future version of Intern, but for the moment Intern doesn't work out-of-the-box with QtWebDriver.
Just getting started with OpenStack.
got everything set up on a Ubuntu VM (under Parallels).
When I attempt to log into the browser console as admin (the password was set during the DevStack install) - I get:
HTTPConnectionPool(host='10.211.55.16', port=8774): Max retries exceeded with url: /v2/a586870bde4c4dfc993dc40cab8047b7/extensions (Caused by <class 'socket.error'>: [Errno 111] Connection refused)
I am however able to run CLI commands such as keystone-tenant-list, and all others, on the actual server.
I made sure that I'm able to ping the virtual Ubuntu host from my Mac. When I first enter http://myhost.mydomain I do get a login page, but, as soon as I enter admin's credentials - I get this ugly (and super long error)
What things could I check to fix this?
Resolution:
1) Wiped clean my Ubuntu host
2) Followed set-by-step instructions here: http://www.stackgeek.com/guides/gettingstarted.html
Everything now works without a glitch.
I'm having trouble with setting up Sentry server in HTTPS mode. Every now and then, reasonably often while seemingly random, this error message gets written by Raven (Sentry client) into log files:
Unable to reach Sentry log server: <urlopen error [Errno 8] _ssl.c:504: EOF occurred in violation of protocol> (url: https://$(valid_server)/)
Web UI works fine. Vast majority of the messages from Raven are received fine and Sentry processes them into usable output. However, due to these errors, something gets lost from time to time.
I have tried to figure this one out, but dead ends seem to follow another. Basically it seems a lot like this:
Python Requests requests.exceptions.SSLError: [Errno 8] _ssl.c:504: EOF occurred in violation of protocol
But when testing my Sentry server with similar s_client query using TLS 1.2, it leads to a valid session unlike with the example there.
It's also not about this, since SNI isn't used:
python-requests 2.0.0 - [Errno 8] _ssl.c:504: EOF occurred in violation of protocol
I'm not able to reproduce the error coherently. Raven's tests are passed and nothing is acutely wrong, until an error pops up in the log.
My set up is: Raven 4.2.1 in Python 2.7.5, Nginx 1.6.0 as reverse proxy handling HTTPS, and finally Sentry 6.4.4 with default Gunicorn 0.17.4. Nginx configs are pretty much similar to official documentation (http://sentry.readthedocs.org/en/latest/quickstart/nginx.html) with a few alterations due to HTTPS.
I ran into the same issue and got it fixed by installing the following dependencies:
On Ubuntu:
sudo aptitude install libffi-dev
And then via pip:
pip install pyopenssl ndg-httpsclient pyasn1
The problem seems to be that Python 2.X doesn't support SNI (which is needed for TLS) out of the box as explained here.