Summary
When running the test suite against an Armadillo backend (e.g. datashield/armadillo_citest), the connection tests fail with SSL errors because the test configuration defaults to DSLiteDriver, which assumes an HTTPS endpoint on port 8443. Armadillo, however, serves over HTTP on port 8080 by default.
This leads to misleading failures such as:
Error in curl::curl_fetch_memory(url, handle = handle):
SSL connect error [localhost]:
OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:8443
even though the container is up and reachable on the correct port (8080).
Steps to Reproduce
- Run dsBaseClient tests using an Armadillo container (e.g. via docker compose with
datashield/armadillo_citest). - Do not set
options(default_driver = "ArmadilloDriver"). - Execute the test suite.
Observed failure occurs in:
test_that("The virtual machine is loaded.", {
response<-httr::HEAD(
url=ds.test_env$ping_address,
config=ds.test_env$ping_config
)
expect_true(http_status(response)$reason%in% c("OK", "Unauthorized"))
})Root Cause
In connection_to_datasets/login_details.R, the driver is determined as:
if (!is.null(getOption("default_driver"))) {
ds.test_env$driver<- getOption("default_driver")
} else {
ds.test_env$driver<-"DSLiteDriver"
}This default cascades into:
DSLiteDriver / OpalDriver → https://<ip>:8443ArmadilloDriver → http://<ip>:8080
As a result, when running against Armadillo without explicitly setting the driver, the tests attempt:
instead of:
Since the Armadillo CI image exposes 8443 but does not provide a valid TLS endpoint by default, the HEAD request fails during the SSL handshake rather than returning a meaningful connection error.
Why This Is Problematic
The failure mode is misleading (SSL error instead of incorrect driver/endpoint).
Port 8443 may appear “ready” at the Docker level (docker-proxy listening), causing long readiness loops and confusing diagnostics.
CI environments using Armadillo (common in DataSHIELD testing) require implicit knowledge to set:
options(default_driver="ArmadilloDriver")
This is not documented in the test setup and can cause unnecessary debugging of networking, TLS, or container readiness.
Expected Behaviour
Either:
- The tests auto-detect the intended backend (e.g. via environment variable or URL scheme), or
- The default driver should not assume DSLite when the test infrastructure commonly uses Armadillo.
At minimum, failures should clearly indicate a driver/endpoint mismatch instead of surfacing as an SSL handshake error.
Proposed Improvements
Possible fixes (any of the following would help):
Document the requirement to set:
options(default_driver="ArmadilloDriver")
when testing against Armadillo.
Allow driver selection via environment variable (e.g. DS_DRIVER) for CI friendliness.
Improve error messaging when ping_address uses HTTPS but the endpoint is HTTP.
Consider making the default driver configurable or context-aware rather than hardcoding "DSLiteDriver".
Workaround
Setting the driver explicitly resolves the issue:
options(default_driver="ArmadilloDriver")
After doing this, the tests correctly target http://<host>:8080 and run successfully against the Armadillo container.
Environment
- Backend: Armadillo (
datashield/armadillo_citest) - Execution: Docker / CI environment
- Observed behaviour: Port 8443 exposed but HTTPS handshake fails; HTTP on 8080 works as expected
Summary
When running the test suite against an Armadillo backend (e.g.
datashield/armadillo_citest), the connection tests fail with SSL errors because the test configuration defaults toDSLiteDriver, which assumes an HTTPS endpoint on port 8443. Armadillo, however, serves over HTTP on port 8080 by default.This leads to misleading failures such as:
even though the container is up and reachable on the correct port (8080).
Steps to Reproduce
datashield/armadillo_citest).options(default_driver = "ArmadilloDriver").Observed failure occurs in:
Root Cause
In
connection_to_datasets/login_details.R, the driver is determined as:This default cascades into:
DSLiteDriver/OpalDriver→https://<ip>:8443ArmadilloDriver→http://<ip>:8080As a result, when running against Armadillo without explicitly setting the driver, the tests attempt:
instead of:
Since the Armadillo CI image exposes 8443 but does not provide a valid TLS endpoint by default, the HEAD request fails during the SSL handshake rather than returning a meaningful connection error.
Why This Is Problematic
The failure mode is misleading (SSL error instead of incorrect driver/endpoint).
Port 8443 may appear “ready” at the Docker level (docker-proxy listening), causing long readiness loops and confusing diagnostics.
CI environments using Armadillo (common in DataSHIELD testing) require implicit knowledge to set:
This is not documented in the test setup and can cause unnecessary debugging of networking, TLS, or container readiness.
Expected Behaviour
Either:
At minimum, failures should clearly indicate a driver/endpoint mismatch instead of surfacing as an SSL handshake error.
Proposed Improvements
Possible fixes (any of the following would help):
Document the requirement to set:
when testing against Armadillo.
Allow driver selection via environment variable (e.g.
DS_DRIVER) for CI friendliness.Improve error messaging when
ping_addressuses HTTPS but the endpoint is HTTP.Consider making the default driver configurable or context-aware rather than hardcoding
"DSLiteDriver".Workaround
Setting the driver explicitly resolves the issue:
After doing this, the tests correctly target
http://<host>:8080and run successfully against the Armadillo container.Environment
datashield/armadillo_citest)