fix(trino-driver): Use SSL options in testConnection

[ovr]

testConnection() issued its GET /v1/info probe via node-fetch without passing the TLS material the driver already resolves from CUBEJS_DB_SSL_* env vars (BaseDriver.getSslOptions). Queries through presto-client honored those options, but the connection test fell back to node-fetch defaults (system CA store, rejectUnauthorized: true) and failed against clusters with custom CAs, self-signed certs, or mTLS.

[claude]

Claude finished @ovr's task in 45s —— View job

---

Code Review

Verdict: Looks good — fix is well-scoped, correct, and tested. No blocking issues.

Details

• Read PR diff and surrounding files
• Analyze correctness / security / tests
• Post review

What the PR does

Wires the already-resolved ssl TLS options (from BaseDriver.getSslOptions) into the node-fetch call in TrinoDriver.testConnection() by attaching an https.Agent when ssl is truthy. Also tightens the PrestoDriverConfiguration.ssl type from string | TLSConnectionOptions to TLSConnectionOptions.

Correctness ✅

• getSslOptions() (packages/cubejs-base-driver/src/BaseDriver.ts:273) returns TLSConnectionOptions | undefined, so narrowing ssl on PrestoDriverConfiguration is consistent with actual usage.
• new HttpsAgent({ ...ssl }) correctly forwards ca, cert, key, rejectUnauthorized, servername, etc. Shallow spread is sufficient — TLSConnectionOptions fields are top-level.
• Behavior parity with presto-client: it uses the same ssl object on its own requests, so the test probe now behaves the same as query traffic.

Minor observations (non-blocking)

1. Agent not destroyed. new HttpsAgent(...) is created per testConnection() call and never .destroy()ed. testConnection runs infrequently (pool init / health check), so this is de-minimis, but you could finally { agent.destroy(); } to be tidy.
2. Type tightening is technically breaking for anyone who consumed the exported PrestoDriverConfiguration type with ssl: string. In practice nothing in this repo passes a string here (only getSslOptions populates it), and presto-client's own types are boolean | ConnectionOptions, not string — so this looks like dead surface area being cleaned up. Fine to keep as-is; worth calling out in the changelog.
3. Empty-object truthiness. protocol = ssl ? 'https' : 'http' and if (ssl) treat {} as SSL-enabled. This matches presto-client's expectations (an empty options object still means "use TLS"), so behavior is aligned end-to-end.

Tests ✅

packages/cubejs-trino-driver/test/unit/ssl.test.ts covers both branches (SSL on → agent attached with correct options; SSL off → no agent, HTTP URL). Good coverage for the fix.

Security ✅

No new attack surface. The change lets operators actually honor CUBEJS_DB_SSL_REJECT_UNAUTHORIZED=false / custom CA that they already configured — same trust decision as normal query traffic.

· [Branch](https://github.com/cube-js/cube/tree/feat/trino-test-connection-ssl)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 59.35%. Comparing base (3a67f7d) to head (461b3a3).

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #11217   +/-   ##
=======================================
  Coverage   59.35%   59.35%           
=======================================
  Files         215      215           
  Lines       17456    17456           
  Branches     3539     3539           
=======================================
  Hits        10361    10361           
  Misses       6589     6589           
  Partials      506      506           

Flag	Coverage Δ
cube-backend	59.35% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.