I’m curious as to why the DBConnector action in my CXone Studio script is failing with a generic ‘Connection Error’ when using credentials stored in HashiCorp Vault? I have configured the DBConnector to use a specific database instance and verified the connection string. The script retrieves the username and password from Vault using the GetSecret action before passing them to the DBConnector. However, the connection fails intermittently. I have checked the Vault audit logs and confirmed that the secrets are being retrieved correctly. The database is accessible from the CXone environment, and other scripts using static credentials work fine. I suspect there might be an issue with how the credentials are being passed or formatted. Is there a specific format or encoding required for the credentials when using Vault? Here is the relevant part of my script:
ASSIGN dbUser = GetSecret("vault-path", "username")
ASSIGN dbPass = GetSecret("vault-path", "password")
DBConnector("my-db", "SELECT * FROM users WHERE id = ?", dbUser, dbPass, [userId])
The error message in the CXone logs is: “DBConnector failed: Connection refused. Please check your credentials and network settings.”
I have verified that the network settings are correct, and the database is accessible. I am using the latest version of the CXone Studio SDK. Any insights on this issue would be greatly appreciated.
Check your **Vault latency**. DBConnector waits for sync resolution. If Vault takes >2s, it drops. Use **DataLoader batching** in your gateway to cache credentials. Avoid per-request fetches.
let timeout = Duration::from_secs(1);
// Ensure Vault resolution completes within DBConnector’s hard limit
This is caused by the DBConnector action enforcing a strict synchronous timeout that fails if your Vault `GetSecret` call exceeds it. You need to cache the credentials in memory or a local store to avoid the network latency penalty on every execution.
Pretty sure the DBConnector action enforces a strict synchronous timeout that fails if your Vault GetSecret call exceeds it. You need to cache the credentials in memory or a local store to avoid the network latency penalty on every execution. The suggestion above regarding DataLoader batching is valid, but you should implement a local TTL cache within your Studio script to decouple the Vault latency from the DBConnector execution path.
Implement a local cache map in your Studio script to store credentials for a short duration (e.g., 60 seconds).
Use a conditional check to retrieve from the cache first, only calling GetSecret if the cache is stale or empty.
Ensure your Vault policy allows read-only access to the specific secret path to minimize permission resolution overhead.
Monitor the execution time of the GetSecret action in the Studio logs to verify it stays under the DBConnector threshold.
This approach reduces the synchronous wait time significantly. If the cache miss occurs, the fallback to Vault happens only when necessary, keeping the DBConnector connection stable.
The documentation actually says… that DBConnector does not support async credential resolution. When you chain GetSecret directly into DBConnector, the platform waits for the HTTP call to complete before establishing the JDBC connection. If Vault takes longer than the internal timeout (usually ~1.5s), the connector drops the request with a generic error.
You should decouple these steps. Use a DataLoader action at the start of the script to fetch secrets from a local cache or a faster source. If you must use Vault, implement a fallback mechanism.
If the local_cache miss triggers a Vault fetch, ensure it runs in a background task or pre-warm the cache during off-peak hours. Do not rely on synchronous Vault calls in the critical path.