Tests default to HTTPS (8443) instead of Armadillo HTTP (8080) unless `options(default_driver = "ArmadilloDriver")` is explicitly set

[villegar]

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

1. Run dsBaseClient tests using an Armadillo container (e.g. via docker compose with datashield/armadillo_citest).
2. Do not set options(default_driver = "ArmadilloDriver").
3. 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>:8443
• ArmadilloDriver → http://<ip>:8080

As a result, when running against Armadillo without explicitly setting the driver, the tests attempt:

https://localhost:8443

instead of:

http://localhost:8080

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

1. The failure mode is misleading (SSL error instead of incorrect driver/endpoint).

2. Port 8443 may appear “ready” at the Docker level (docker-proxy listening), causing long readiness loops and confusing diagnostics.

3. CI environments using Armadillo (common in DataSHIELD testing) require implicit knowledge to set:

   options(default_driver = "ArmadilloDriver")

4. 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):

1. Document the requirement to set:

   options(default_driver = "ArmadilloDriver")

   when testing against Armadillo.

2. Allow driver selection via environment variable (e.g. DS_DRIVER) for CI friendliness.

3. Improve error messaging when ping_address uses HTTPS but the endpoint is HTTP.

4. 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

[StuartWheater]

The DSLiteDriver shouldn't need a running server, so not sure why requires HTTPS endpoint.

The port used is set in "tests/testthat/connection_to_dataset/login_details.R" based on the driver specified { "DSLiteDriver", "OpalDriver" or "ArmadilloDriver" }. This file is also used to check if "default_driver" option is set, if not can specify a "hardwired" default.

"default_driver" option is used to communicate between pipelines and tests suite.