Health-probe the seeded Host Snowflake connection under the caller's own rights.
Snowflake mode only. Unlike POST /v1/connections/{id}/test — admin-gated, runs under the stored service credential, and has nothing to test for the secretless spcs_token host connection — this runs four read-only checks under the REQUESTING USER's own Snowflake rights (caller's-rights, DVT-1385), never a service identity: session (does the caller's token resolve to a live Snowflake session), warehouse (does the session have a usable warehouse — the caller's own default, or the app's consumer-bound fallback warehouse, DVT-2192), databases (can the caller see any database at all — the most common "why is my dashboard empty" cause under caller's-rights grants, DVT-1767), and cortex (DVT-2193: SHOW PARAMETERS LIKE 'CORTEX_CODE_%' — has an admin silently zeroed the Cortex Code daily credit limit, killing the in-app AI helper with no actionable error anywhere else; this check fails ONLY on an explicit 0-credit limit and neutral-passes when that can't be determined on this account). Any authenticated member may call it; it is not admin-scoped. Stamps lastTestedAt (and, on failure, lastTestError) onto the host connection, exactly like the admin test endpoint — EXCEPT cortex is advisory-only and never contributes to that persisted failure stamp (a 0-credit Cortex Code limit says nothing about whether the connection can serve queries, so it must not false-alarm /admin/health's "needs attention" surface); a cortex-only failure still flips this response's own ok to false, but leaves lastTestError unset.
writeback (DVT-2905 slice B, ADR-0077 r3) is a SEPARATE, additive best-effort field, snowflake mode only: whether the org's dvt_writeback database is provisioned (an admin has run the two-statement grant from the Sheets setup panel) and the Snowflake APPLICATION database name, for templating GRANT ... TO APPLICATION "<name>" in the admin panel. It runs under APP IDENTITY (never the caller's own token), so it is independent of the four caller's-rights checks above and is present even when session fails. Present only when the org has a live boot-provisioned Host Snowflake Writeback connection to probe; omitted everywhere else (gallery/enterprise, or a snowflake deployment where writeback hasn't provisioned yet) — never contributes to this response's ok or the persisted lastTestError stamp.
A per-check failure is a normal 200 — the check ran and answered "no", which is the useful signal. Off snowflake mode, this route does not exist (404, leak-safe). A genuine engine/infra fault (unreachable, at-capacity) aborts the whole probe with a non-200 rather than a misleading partial result.
Request
- Base URL: http://localhost:8080
- URL: http://localhost:8080/v1/connections/host/test
- Auth: one of:
- API key in cookie dvt_session
- HTTP bearer
Response
The probe outcome — four itemized checks plus the overall ok.
Changes
No recorded changes to this operation across all 1 revision of this API.