SQL Editor live evidence — Classic mode

This page records the first safe runtime pass against the deployed SQL Editor. It confirms only the environment, role, actions, and observations stated here. It does not establish support for other roles, workspaces, data sources, scale boundaries, failure modes, or Nitro execution.

Observation context

Field	Observed value
Observation date	31 August 2026
Deployed topology observation	3 September 2026; read-only Trino, autoscaler, Hive Metastore, and metadata PostgreSQL inventory
Page	https://platform.cogrion.com/admin/sql
Workspace	w-t5e2kcxjd (visible name alicloud01)
Deployment identity	Keycloak realm gj76anadpsc; workspace w-t5e2kcxjd; Kubernetes context dev-north-alicloud
Visible account role	admin
Execution mode	Classic
Initial catalog and schema	delta.default
Initial requested row limit	1,000
Browser evidence mode	Headed Chromium with video, trace, network log, snapshots, and selected screenshots
Query data	Self-contained literals and a bounded Trino TABLE(sequence(...)) generator only; no customer tables were read
Persistent changes	One Untitled 1 saved query was created by the Save control, positively identified by its SQL, and deleted during the same run
Temporary tab changes	Nine test-only tabs were created across the persistence, concurrency, repeat-query, preview, and scale passes and closed after evidence capture; the original tab name was restored to Untitled 1
Download cleanup	Temporary CSV, PNG, PDF, and rendered-PDF files were deleted after content verification

The raw artifacts remain in the assessor's temporary working directory and are not yet durable evidence. They must be moved to an approved restricted evidence store before owner review. Playwright trace and network files can contain authenticated headers and must not be committed without sanitization. No credentials, tokens, cookies, or browser storage values were copied into this documentation.

Detailed scenario results

The scenario IDs below are retained only for assessment traceability. Readers looking for the current product status and findings should start with SQL Editor — Classic mode.

Scenario	Action and data	Observed result	Assessment state
SQLC-S001	Open /admin/sql after authentication	The page loaded in alicloud01 with one Untitled 1 tab, delta.default, Classic selected, limit 1,000, an empty editor, and an initial result prompt. Schedule was disabled.	Observed for one admin account
SQLC-S005	Leave SQL Lab for Dashboard Builder and Saved queries, then return directly to /admin/sql	Tab name, SQL text, catalog, schema, and three-row result returned. The visible execution status reset from Succeeded to Ready. Cross-workspace isolation was not tested.	Partially observed
SQLC-S006	Run distinct literal-only queries in PW Persist A and PW Persist B, then switch between the tabs	Each tab retained its own SQL and result marker: A returned PW_PERSIST_A_20260831 and 101; B returned PW_PERSIST_B_20260831 and 202.	Observed
SQLC-S007	Explicitly select PW Persist B, reload /admin/sql, and revisit the tab after navigating to Queries	The tab list, selected B tab, SQL, and IndexedDB-backed result returned after reload. The result also remained after in-app navigation to /admin/queries and back. Its visible status changed from Succeeded to Ready.	Observed with status limitation
SQLC-S008	Add Untitled 5 while PW New Active was the previously saved active tab, then reload without clicking the new tab	Untitled 5 was visibly active before reload, but the saved active-tab pointer still named PW New Active. Reload activated PW New Active, not the newly created tab.	Defect observed
SQLC-S009	Start sum(sqrt(sequential_number)) over TABLE(sequence(start => 1, stop => 20000000, step => 1)) in PW Concurrency Long; while its tab spinner remained active, switch to PW Concurrency Quick and run a literal query	The quick tab entered Executing while the long tab still showed its independent running spinner. Both execute requests returned HTTP 200. Quick reported Succeeded in 0.95 seconds; long reported Succeeded in 1.05 seconds. Each tab retained its own result.	Observed for two overlapping, bounded, read-only queries; not a capacity boundary
SQLC-S010	Run the exact SQL SELECT current_timestamp AS observed_at, uuid() AS run_marker twice in one tab	Both Runs issued execute requests and returned HTTP 200. They returned distinct execution records (177, 178), Superset result keys, timestamps, and UUID values. UI durations were 1.20 and 0.65 seconds. Superset cached each completed output separately; the second Run did not reuse the first.	Result persistence observed; same-SQL reuse not observed; lower-layer warming not excluded
SQLC-S013	Rename Untitled 1 to PW Rename 20260831, save, reopen Rename, and restore the original name	The active tab label changed after each non-blank Save. Source confirms this is browser tab state only, not a saved-query rename or backend request. Blank-name validation was not tested.	Observed for non-blank local rename
SQLC-S014	Format select 1 as assessment_probe where false	Format SQL returned SELECT 1 AS assessment_probe and WHERE FALSE on two lines without executing the statement. Invalid-format failure was not tested.	Partially observed
SQLC-S018	Run SELECT 1 AS assessment_probe	Classic returned one column, one row with value 1, Succeeded in 0.90 seconds, and estimate fields. The execute and estimate requests both returned HTTP 200.	Observed
SQLC-S020	Run SELEC 1 AS invalid_probe once	The page showed Failed and a Trino syntax error with query ID while preserving the SQL. The previous successful estimate footer remained visible, and the single Run action produced three failed execution requests. Source inspection matched these to one initial client POST plus two retries, not polling.	Observed + source-matched; history and engine effects not correlated
SQLC-S022	Run SELECT 1 AS assessment_probe WHERE FALSE	The page showed Succeeded in 0.70 seconds and a distinct No data message stating that the query returned no rows. Estimate fields showed zero rows and zero output bytes.	Observed
SQLC-S027	Replace the failed statement with the zero-row statement and run again	The later statement succeeded and replaced the Failed state with No data.	Observed
SQLC-S029	Inspect estimate after successful queries	The one-row, zero-row, and three-row executions displayed total rows, CPU cost, output size, and duration. Accuracy and estimate-failure behavior were not established.	Partially observed
SQLC-S030	Use a three-row literal result, search for beta, clear search, and sort id	Search reduced three rows to the one beta row; clearing restored all rows; sorting displayed IDs in descending order. A multi-page boundary was not tested.	Partially observed
SQLC-S031	Open the beta cell and close its viewer	The viewer identified column category, displayed the full value, and exposed Copy and Close. Copy, empty values, and truncation boundaries were not tested.	Partially observed
SQLC-S035	Visualize three rows as a bar chart with category X axis and summed numeric ID	The chart rendered alpha as 4 and beta as 2. The other seven chart families were visible but not exercised.	Partially observed
SQLC-S036	Export the bar chart as PNG and PDF	Both downloads opened and visually matched the displayed chart, with readable axes and no clipping. Files were deleted after verification.	Observed for Bar
SQLC-S037	Select Create Dashboard	The browser opened /admin/builder?from=visualization with one unsaved Bar Chart. Create was not selected, and returning to SQL Lab preserved the SQL and results.	Observed through handoff
SQLC-S038	Open Past Execution before and after the SQL page remounted	Existing entries were visible. Runs from the active page session did not appear until remount. After remount, the three-row SQL appeared twice: once for SQL Lab execution and once after the Dashboard Builder used the catalog query path. Empty history and copying an entry were not tested.	Partially observed
SQLC-S039	Select Save once on the local Untitled 1 tab	Save immediately issued a successful create request without a confirmation dialog or visible success message. The exact saved record was verified by owner, catalog, schema, time, and SQL, then deleted.	Observed with gaps; cleaned up
SQLC-S041	Open a PW Cache Probe history record in Query preview and select Open in SQL Lab	Preview showed Query name, User query, Executed query, and SQL. Open in SQL Lab returned to /admin/sql, activated a PW Cache Probe tab, and loaded the SQL in Ready state with no result. No execution request was observed. The tab was closed.	Observed; preview is a non-executing handoff
SQLC-S042	Open and close Share without changing a field	The dialog identified Untitled 1, showed Copy link, a user/group selector, inherited access for the current user and Admins, and sharing settings. The page remained at /admin/sql with no query identifier in the URL.	Observed; source confirms no canonical share target
SQLC-S044	Inspect credential text without changing it	The dialog displayed Run as owner with the owner's credential and explained its effect on viewers and editor/manager access. Source confirms the credential and principal selections are local state with no query-bound access mutation.	Observed + source-verified presentation only
SQLC-S045	Inspect Schedule	Schedule was visible and disabled throughout the run.	Observed; intent pending
SQLC-S046	Run a bounded Trino sequence returning 10,000 rows with columns id, unique label, and 100-value bucket; set LIMIT 10,000	Classic succeeded in 1.65 seconds. Raw Result displayed 50 rows per page and reported Showing 1 to 50 of 10000 results. Searching row-10000 returned the final row and reported one result.	Observed for one generated 10,000-row payload; not an upper boundary
SQLC-S047	Visualize the same 10,000 rows as a Bar chart, first using unique label, then 100-value bucket, then label again	The 10,000-category chart area was blank on first render with no application console error. Changing X to bucket rendered 100 categories. Returning to label forced a rendered but unreadably compressed chart. Reopening Visualization later delayed browser inspection by about 20 seconds before recovery.	High-cardinality instability observed; no supported chart boundary established
SQLC-S048	Run SELECT CAST('not-a-number' AS INTEGER) once in Classic mode	The UI ended in Failed with Trino INVALID_CAST_ARGUMENT. The one Run produced three HTTP 500 execute responses and three distinct Trino query IDs.	Observed 2026-09-01; deterministic execution failure, not syntax validation or OOM
SQLC-S049	Inspect the deployed Trino coordinator, worker, gateway, autoscalers, and workload-admission configuration without changing them	On 3 September 2026, the assessed deployment had one fixed coordinator and one fixed worker. Only the gateway had a horizontal autoscaler. No active Trino resource-group or equivalent query-admission policy was evidenced.	Deployed topology + source verified; no saturation or scaling test performed
SQLC-S050	Compare the product SQL Editor lifecycle with the platform's named Trino-cluster deployment capability	Platform source can deploy and register a named additional cluster, but the current flavor and deployed workspace use one defaultcluster. SQL Editor exposed no Compute selector or create, resize, start, stop, status, recover, or delete lifecycle.	Source-verified architecture gap; future lifecycle acceptance pending
SQLC-S051	Inspect the HMS capacity interface and deployed service/database topology, placement, autoscaling, disruption, database routing, storage, and monitoring without changing them	Source exposed installer Size options from small through xlarge, but they changed only fixed HMS replicas/resources. On 3 September 2026, HMS had two fixed healthy pods; PostgreSQL had one small fixed replica and a 20 GiB volume. No end-to-end metadata capacity profile or managed autoscaling was evidenced.	Interface source + deployed topology verified; post-deployment resize, metadata load, failover, backup, restore, and storage boundaries not tested

Runtime request evidence

The browser network log confirmed these page-level paths through the workspace-specific BFF:

Purpose	Observed request outcome
Load query history	Query-history request returned HTTP 200 on SQL page mount
Load databases and schemas	Database and schema requests returned HTTP 200
Successful Classic execution	SQL Lab execute returned HTTP 200
Successful estimate	SQL Lab estimate returned HTTP 200
Valid format	SQL Lab format returned HTTP 200
Invalid Classic execution	One invalid-syntax Run produced three SQL Lab execute requests, each HTTP 500
Trino execution failure	One INVALID_CAST_ARGUMENT Run produced three SQL Lab execute requests, each HTTP 500, with distinct Trino query IDs
Two-tab concurrent Classic execution	Two overlapping SQL Lab execute requests returned HTTP 200, followed by successful estimate requests
Exact repeat Classic execution	Two identical SQL Lab execute requests returned HTTP 200 with distinct execution records and result values
Query preview handoff	Preview loaded the selected history SQL into a SQL Editor tab; no execute request was observed until a user Run action
10,000-row Classic execution	One generated-sequence SQL Lab execute returned HTTP 200; the complete result was retained client-side and paged in the browser
Save local query	Saved-query create returned HTTP 200
Dashboard handoff	Dashboard Builder submitted the same SQL through the catalog query path and returned HTTP 200

This confirms the browser-to-BFF request boundary. It does not independently prove the internal BFF-to-Superset, Superset-to-Trino, identity, Ranger, metastore, or object-storage hops.

Observations and reproduction

Each coded observation combines what happened, how it was verified, and how to reproduce it. The IDs link back to the findings summary on the main page.

Unless a procedure says otherwise, use realm gj76anadpsc, workspace w-t5e2kcxjd (alicloud01), /admin/sql, delta.default, and Classic mode. Use only the literal and generated fixtures below or an explicitly approved table. Close temporary tabs and delete temporary saved queries afterward.

PROD-SQL-002

Autocomplete is not semantic

Tracking: sparqd/oqullus#509 for semantic completion and validation; sparqd/oqullus#508 for consistently visible suggestion-type labels.

Method: Safe runtime plus source inspection.

1. Expand one approved table in the warehouse tree so its columns are loaded.
2. Type SELECT t. FROM <catalog>.<schema>.<approved_table> AS t and invoke completion after t..
3. Compare the suggestions with that table's columns and with columns loaded from other tables. Type a nonexistent column without running the query and check for a diagnostic.
4. Inspect oqullus/src/components/shared/QueryEditor/index.tsx: the completion provider concatenates fixed keywords with globally extracted database, schema, table, and column names without parsing FROM, aliases, joins, or CTEs.

The finding is reproduced when suggestions are not restricted to the aliased table and an unknown identifier is not rejected before execution.

UX-SQL-005

Failed runs retain prior output

Tracking: sparqd/oqullus#507. The cross-reload persistence boundary is tracked separately in sparqd/oqullus#511.

Method: Safe runtime plus source inspection; observed and source-verified.

1. Run SELECT 1 AS assessment_probe and record the successful result and estimate footer.
2. Replace it with SELEC 1 AS invalid_probe and select Run once.
3. Confirm the state is Failed, then inspect the Raw Result area and estimate.
4. Open Visualization. Confirm it receives the previous successful rows and does not show the failed-query warning inside the visualization view.
5. Inspect oqullus/src/context/query/QueryContext.tsx: the failure path sets the execution error but does not clear the tab's prior results or estimate.
6. Inspect oqullus/src/pages/Dashboard/SQL/SQLEditor/index.tsx: when Visualization is selected, SQLVisualization is rendered with activeTab.results before the conditional branch that renders errorResult.

The finding is reproduced when metadata or output from the successful run remains visible after the failed run. Do not treat retained output as partial output from the failed statement. In the observed run, the failed syntax still showed the previous query's total Rows: 1 rows estimate. The concrete UX risk is stronger in Visualization: opening that tab after the failure can display a chart of the previous successful query without the failure warning, making the stale chart appear to belong to the failed statement.

REL-SQL-001

One Run can send repeated failed requests

Tracking: sparqd/oqullus#510.

This is client retry behavior, not polling. One Run calls executeQuery once, but the shared withRetry wrapper classifies HTTP 500 as retryable and permits two retries after 500 ms and 1,000 ms. The BFF forwards each incoming request once and adds no polling or retry loop. Any failure represented by this endpoint as HTTP 500 is therefore retried as though it were transient. This includes at least invalid syntax and the live-tested Trino INVALID_CAST_ARGUMENT; OOM was not tested.

Method: Safe runtime with browser network evidence plus UI and BFF source inspection; observed once and source-matched.

1. Start a browser trace or clear the Network panel.
2. Run SELECT CAST('not-a-number' AS INTEGER) exactly once. This produces a deterministic Trino execution failure without scanning a table or creating material memory pressure.
3. Filter requests for /superset/api/v1/sqllab/execute/ and count requests attributable to that one action.
4. Record request timestamps, status codes, and execution records without copying authenticated headers.
5. In the reviewed Oqullus source, follow executeQuery → useHttpTemp.post → httpTempPost → withRetry. Confirm maxRetries = 2, HTTP 500 is retryable, and the delays are 500 ms and 1,000 ms.
6. In the reviewed BFF source, inspect the SQL Lab execute route and confirm it forwards each incoming POST once to Superset without a polling loop.

The assessment observed three HTTP 500 requests, matching one initial client POST plus the two configured retries. Their Trino query IDs were 20260901_041648_00045_2teyk, 20260901_041649_00046_2teyk, and 20260901_041651_00047_2teyk. The distinct IDs prove that the retries repeated engine execution; they were not status polling. A different live count must be recorded rather than forced to match the source default because configuration or code may change. OOM and infrastructure failures were not injected, but if they are surfaced as HTTP 500 the same generic retry condition applies.

ARCH-SQL-002

Results use custom IndexedDB persistence

Tracking: sparqd/oqullus#511.

Method: Safe runtime plus source inspection; persistence observed.

1. Run SELECT 'PW_INDEXEDDB_PROBE' AS marker in a temporary tab.
2. In browser storage tools, inspect IndexedDB database sqlLabResultsDB, object store tabResults, and the record keyed as <user>__<tab>.
3. Reload SQL Lab and confirm the row returns without calling Superset's /api/v1/sqllab/results retrieval endpoint.
4. Inspect oqullus/src/utils/sqlLabStorage.ts and the execute/hydration paths in oqullus/src/context/query/QueryContext.tsx.

The finding is reproduced when Oqullus restores its browser copy while ignoring the Superset resultsKey. Close the tab and confirm its IndexedDB record is removed.

UX-SQL-002

Inline history is stale until remount

Tracking: sparqd/oqullus#512.

Method: Safe runtime; observed.

1. Run SELECT 'PW_HISTORY_REFRESH_PROBE' AS marker.
2. Open Past Execution without leaving or reloading SQL Lab and search for the marker.
3. Reload or navigate away and return, reopen Past Execution, and search again.

The finding is reproduced when the new execution is absent before remount and present afterward.

UX-SQL-003

Save conflates browser drafts with persisted query state

Tracking: sparqd/oqullus#515.

Method: Safe runtime with cleanup plus source inspection; observed and source-verified.

The editor has three different persistence paths that are not distinguished in the UI:

• Editing SQL, renaming a tab, or changing catalog/schema writes the tab state to browser localStorage. SQL changes are written on every editor change, without a debounce. This is browser-only draft persistence, not a backend Saved Query.
• Run does not create or update a Saved Query. It submits an execution that is recorded separately in query history and the result backend.
• Save or Ctrl/Cmd+S creates a Saved Query with POST when tab.id is a local UUID, or updates with PUT when tab.id is numeric. There is no Save As step, dirty indicator, or explicit distinction between a recovered draft and a persisted query.

1. Create and rename a temporary tab to a unique PW Save Probe <timestamp> name and enter SELECT 'PW_SAVE_PROBE' AS marker.
2. Select Save once and record whether a confirmation or visible success state appears.
3. Open Saved queries and locate the exact record by name, SQL, owner, and time.
4. Delete that record and confirm it is gone.

The finding is reproduced when Save creates the record immediately without a naming/confirmation step or clear completion evidence. The live assessment verified create and cleanup; backend update and failure were not injected.

Source inspection also identified two unverified failure modes:

• After the create POST, the new numeric saved-query ID replaces the local UUID in React state but is not immediately written to localStorage. An immediate reload can restore the old UUID, so a later Save can take the create path again. Reproduce with a temporary query by Save → immediate reload → edit → Save, then count exact saved records and delete all probes.
• saveQuery catches backend errors instead of rethrowing them. Its caller therefore advances the shared save progress to 100 percent even after the query save failed, while only the toast reports failure.

Expected solution:

1. Model local tab identity, backend saved-query identity, and execution identity as separate fields. Do not replace a local tabId with a backend resource ID.
2. Label browser persistence as a local draft, scope it by realm, workspace, user, and tab, and debounce writes. Show Unsaved changes and the last successful backend-save time.
3. Make first persistence an explicit Save As flow that confirms the query name and creates one backend resource. Subsequent Save actions update that resource. Run remains independent and must not silently save the definition.
4. Persist the returned savedQueryId atomically before reporting success so a reload cannot turn the next Save into another create.
5. Propagate save failures to the caller. Show Saving, Saved, and Save failed truthfully, retain the dirty state after failure, and offer retry.
6. Keep Delete as a separate confirmed action and define recovery for deleted, forbidden, renamed, or concurrently modified saved queries.

Acceptance requires automated coverage for local draft recovery, first Save, repeat Save/update, immediate reload after create, rename before and after Save, Run without Save, backend failure and retry, concurrent edits, workspace isolation, and prevention of duplicate records.

PROD-SQL-001

Restored results display Ready

Related tracking: sparqd/oqullus#511.

Method: Safe runtime; observed.

1. Run SELECT 'PW_RESTORE_STATUS' AS marker and confirm Succeeded.
2. Navigate to /admin/queries and back, or reload SQL Lab.
3. Confirm the SQL and row are restored and inspect the execution status.

The finding is reproduced when the prior result remains but the status changes from Succeeded to Ready.

UX-SQL-006

A newly added active tab is not restored as active

Method: Safe runtime with cleanup; observed and source-confirmed.

1. Explicitly click an existing tab A so its active-tab pointer is persisted.
2. Add tab B and, without clicking B again, enter a unique SQL marker.
3. Reload the page.
4. Confirm tab B and its SQL still exist, then record which tab is active.

The finding is reproduced when tab A becomes active after reload even though B was visibly active before reload. Source confirmation is in addTab in oqullus/src/context/query/QueryContext.tsx, which uses the raw active-state setter rather than the persistence-aware setter.

UX-SQL-004

Icon controls lack accessible names

Method: Safe runtime accessibility snapshot; observed.

1. Open SQL Lab with Raw Result and Past Execution controls visible.
2. Capture an accessibility snapshot, for example playwright-cli snapshot --filename=sql-editor-a11y.yaml.
3. Inspect toolbar, result-search, result-close, and history-close buttons for an accessible name derived from text, aria-label, or title.

The finding is reproduced when an actionable icon is exposed only as an unnamed button. Record exact controls because not every icon is affected.

REL-SQL-002

Visualization failure can replace the editor

Method: Source inspection. This is a containment risk, not a demonstrated runtime crash.

1. Inspect oqullus/src/pages/Dashboard/SQL/SQLEditor/index.tsx.
2. Confirm AppErrorBoundary wraps SQLEditorComponent, Share, the SQL editor, Raw Result, and Visualization together.
3. Confirm SQLVisualization has no chart-local error boundary.

The source condition is verified when a render exception from Visualization would reach the SQL Editor-level boundary. Demonstrating the visible failure requires approved fault injection with malformed chart data.

GOV-SQL-001

High-cardinality visualization is unstable

Method: Safe bounded runtime; observed. The fixture generates data and does not read customer tables.

1. Create a temporary tab, choose LIMIT 10,000, and run:

   SELECT
     sequential_number AS id,
     concat('row-', CAST(sequential_number AS varchar)) AS label,
     mod(sequential_number, 100) AS bucket
   FROM TABLE(
     sequence(start => 1, stop => 10000, step => 1)
   )

2. In Raw Result, confirm Showing 1 to 50 of 10000 results. Search for row-10000 and confirm the final row is returned.

3. Open Visualization, select Bar, set X to label, Y to id, and aggregation to Sum. Record blank, delayed, or compressed output.

4. Change X to bucket and confirm the same rows render as 100 categories.

5. Change X back to label, record render and recovery behavior, then close the temporary tab.

The finding is reproduced when Raw Result remains usable but the 10,000-category chart is blank, delayed, or unreadable while 100 categories render. The initial blank is timing-dependent; reopening Visualization later delayed browser inspection by about 20 seconds. Do not increase to 100,000 rows without an approved performance-test window.

PROD-SQL-003

Sharing lacks a canonical query identity and deep link

Tracking: sparqd/oqullus#505.

Method: Safe runtime plus source inspection; source-verified.

1. Open Share from an unsaved tab and record the browser URL. Confirm the modal does not identify a persisted query resource and the URL remains /admin/sql without a query ID.
2. Save a temporary query and inspect the create response. Confirm the backend returns a numeric saved-query ID.
3. Inspect QueryTab and saveQuery in oqullus/src/context/query/QueryContext.tsx. The same tab.id field holds a local UUID before Save and is replaced with the numeric saved-query ID after Save; there is no explicit savedQueryId or saved-resource state.
4. Inspect ShareQueryModal/index.tsx. It receives activeTab but uses only the tab name, does not bind sharing to activeTab.id, and gives Copy link no handler. Principal and credential choices remain component state with no apply/save request.
5. Inspect the SQL routes and Queries-page handoff. /admin/sql and /admin/queries have no query identifier parameter; preview resolves an ID from an in-memory list, and Open in SQL Lab passes the query object through context before navigating to the static /admin/sql route.
6. Attempt to form a URL that another authorized user could open to resolve the same saved query. Record that the current routing contract provides no such URL or loader.

The finding is source-verified when a saved-query ID exists but Share neither binds to it nor exposes a route that resolves it. The inert Copy link is a symptom of the missing resource and routing contract, not the primary defect. A complete design needs a canonical workspace-scoped query URL, load-by-ID behavior, authorization on resolution, and persisted sharing changes.

PROD-SQL-005

Schedule is surfaced but permanently disabled

Tracking: sparqd/oqullus#506.

Method: Safe runtime plus source inspection; observed and source-verified.

1. Open /admin/sql in Classic mode and locate Schedule beside Save.
2. Confirm the button is visible but disabled before entering SQL, after entering SQL, and after a successful read-only execution.
3. Inspect oqullus/src/pages/Dashboard/SQL/SQLEditor/index.tsx and locate the Schedule button.
4. Confirm it is rendered with the unconditional property disabled={true} and has no onClick handler or conditional availability expression.

The finding is source-verified when the button is always disabled in the reviewed implementation. This is not evidence of a temporary permission or loading state. Implement the workflow or remove the surfaced control.

SEC-SQL-001

Chart tooltip encoding is not established

Method: Source inspection only. This is a security-review finding, not a demonstrated vulnerability.

1. Inspect tooltip formatters in oqullus/src/pages/Dashboard/SQL/SQLEditor/SQLVisualization.tsx.
2. Trace returned category names and result values into formatter template strings containing HTML such as <br/>.
3. Confirm no explicit inert-text encoder or tooltip rendering contract is applied before returning the string.

The source condition is verified when result-controlled text is interpolated without an explicit encoding boundary. Do not test executable payloads in the deployed workspace; exploitability requires an approved security fixture and browser security review.

ARCH-SQL-001

Browser state lacks workspace identity

Method: Source inspection; controlled runtime verification remains open.

1. Inspect local-storage keys in oqullus/src/context/query/QueryContext.tsx; tab and active-tab keys include user identity but not workspace identity.
2. Inspect oqullus/src/utils/sqlLabStorage.ts; result keys are <user>__<tab> and also omit workspace identity.
3. Inspect the initialization guard: it resets when no workspace is active, not on every direct switch between populated workspaces.
4. In a controlled test with two authorized workspaces, create a non-sensitive marker tab in workspace A, switch to B without executing it, and record whether A's tab or result appears. Clean both workspaces afterward.

The source risk is verified by the key design. Cross-workspace disclosure is not demonstrated unless step 4 exposes A's state in B.

REL-SQL-003

Stop provides client-side cancellation only

Method: Source inspection plus controlled engine correlation; upstream behavior remains unverified.

1. Inspect cancelExecution in oqullus/src/context/query/QueryContext.tsx: it aborts the browser request, clears local result/estimate state, and sends no explicit server-side stop request or Superset client_id.
2. In an approved performance window, run a bounded long query and capture its Superset and Trino identifiers.
3. Select Stop once, then query authorized Superset, gateway, and Trino telemetry until the engine reaches a terminal state.

The client limitation is source-verified. Upstream cancellation is demonstrated only if correlated engine evidence shows Cancelled rather than continued work or normal completion.

PROD-SQL-004

Nitro exposure and support are unresolved

Method: Source and deployment inspection; owner confirmation required.

1. Inspect EXECUTION_MODE_OPTIONS in oqullus/src/pages/Dashboard/SQL/SQLEditor/index.tsx: Nitro is included unconditionally while a nearby comment says LTAP is environment-restricted.
2. Inspect the accelerated route in oqullus/src/context/query/QueryContext.tsx, which sends /ltap/query.
3. Inspect platform-stacks/kcl/flavors/delta-spark/main.k, where LTAP is configurable and defaults enabled in the reviewed source.
4. Obtain the environment owner's supported realm/workspace matrix before any Nitro execution test.

The conflict is reproduced when the selector, comment, route, and deployment defaults do not establish one support rule. This procedure does not claim Nitro is broken; its support status remains unverified.

SQLC-S049

Fixed query capacity and absent workload admission

Method: Read-only deployment and source inspection; controlled load remains open.

1. In Kubernetes context dev-north-alicloud, inspect the Trino coordinator, worker, and gateway replica counts and resource requests for realm gj76anadpsc, workspace w-t5e2kcxjd.
2. List autoscalers and distinguish gateway replicas from Trino query workers.
3. Inspect the current platform deployment contract for the Trino capacity profile, worker count, worker autoscaling, graceful shutdown, metrics, and workload-admission policy.
4. Record the topology without copying secrets or mutable credentials.
5. In an approved performance environment, separately ramp bounded read-only concurrency and record query IDs, running and queued counts, completion and rejection states, latency, memory pressure, worker changes, cancellation, and recovery. Stop before crossing the agreed safety boundary.

Steps 1–4 verified one fixed coordinator and worker, gateway-only autoscaling, and no evidenced admission policy on 3 September 2026. They do not establish a performance limit. Step 5 remains blocked on an approved load-test boundary. See PERF-SQL-001.

SQLC-S050

Named cluster deployment is not a managed product lifecycle

Method: Source and deployed inventory inspection; future acceptance test remains open.

1. Inspect the platform's Trino cluster deployment contract and confirm it can name, size, deploy, and register an additional cluster through an operator workflow.
2. Inspect the default flavor and deployed gateway inventory; record how many query clusters are configured and ready.
3. Open /admin/sql and confirm whether the product exposes a logical Compute selector or create, resize, start, stop, status, recover, and delete states.
4. Do not interpret Catalog as Compute: record Catalog, Schema, Mode, and Compute as separate concepts.
5. For future acceptance, create an approved logical compute, wait for Ready, route a bounded query, resize, stop, restart, simulate a recoverable failure, and delete it. Verify permissions, quotas, audit, rollback, and that the same effective user receives the same Ranger/catalog authorization across computes.

Steps 1–4 verified an operator deployment primitive, one current defaultcluster, and no managed product lifecycle. Step 5 is an acceptance scenario for a future capability, not a claim that it exists today. See ARCH-SQL-003.

SQLC-S051

Hive Metastore capacity and availability are not managed end-to-end

Method: Read-only source and deployed inventory inspection; load, disruption, and recovery testing remains open.

1. Inspect the platform installer contract for HMS Size options and record which HMS and PostgreSQL capacity fields each tier changes.
2. In Kubernetes context dev-north-alicloud, inspect HMS replica count, readiness, resources, Service endpoints, HPA, PodDisruptionBudget, affinity, and topology-spread configuration for realm gj76anadpsc, workspace w-t5e2kcxjd.
3. Inspect the metadata PostgreSQL replica count, resources, volume size, termination policy, service ports, and exporter state without reading credentials or connection secrets.
4. Compare the HMS database destination with the direct and pooled PostgreSQL service ports. Inspect whether an aggregate connection-pool budget is explicitly configured.
5. Inventory Trino and Spark consumers that share the HMS service. Treat every added compute cluster or concurrent Spark workload as metadata demand.
6. Record current health and placement separately from enforced availability policy; two pods on different nodes at one instant do not prove anti-affinity or disruption protection.
7. In an approved test environment, change the logical metadata capacity tier through the supported administrator interface. Record validation, affected tiers, expected disruption, progress, success or failure, and rollback. Do not change raw pod, JVM, or database fields through the product surface.
8. In an approved performance environment, exercise bounded concurrent catalog browsing and partition-heavy query planning while measuring HMS latency, errors, threads and pools plus PostgreSQL connections, locks, latency, CPU, memory, and storage. Increase HMS replicas only within the database connection budget.
9. With restorable test metadata, exercise one HMS-pod disruption, PostgreSQL failover, backup restore, and storage warning/exhaustion recovery. Record client errors, retry behavior, recovery time, and metadata correctness.

Steps 1–6 verified the fixed Size options, service, and single-database topology on 3 September 2026. They do not establish safe post-deployment resize, throughput, failover, or recoverability. Steps 7–9 require an approved environment and recovery fixture. See PERF-SQL-002.

Additional observations

• Repeat Run executes again; this is not classified as a finding. Two explicit Runs of SELECT current_timestamp AS observed_at, uuid() AS run_marker produced separate requests, execution IDs, result keys, timestamps, and UUIDs. This is a reasonable freshness-preserving default: identical SQL can depend on changing data, time, nondeterministic functions, identity, session state, or current policies. No final-result reuse was observed, although lower engine and storage caches may still warm. An alternative such as opt-in result reuse would need explicit freshness and invalidation semantics; the assessment found no requirement for it.
• Dashboard handoff added a second history entry. SQL Lab executed the three-row statement once. Dashboard Builder later sent the same SQL through the catalog query path, and Past Execution showed the SQL twice. This is recorded in scenarios SQLC-S037 and SQLC-S038; whether those entries should remain distinct was not assessed.
• A background development-host request failed. Initial page load in realm gj76anadpsc, workspace w-t5e2kcxjd, attempted to resolve an ontology projects endpoint on a development BFF hostname and received a DNS failure. SQL execution continued through the workspace BFF, so this was outside the Classic execution path.

Evidence still required

The run did not attempt restricted-role access, cross-workspace isolation, warehouse mutations, selection-only execution, keyboard shortcuts, sustained or higher-width concurrency, cancellation, timeout, dependency outage, unauthorized data access, 100,000-row or memory limits, server-side limit enforcement, raw-result CSV/TSV/Excel controls, partial or interrupted output, empty, malformed, mixed, or untrusted visualization data, chart-local failure containment, every chart family, Trino-aware SQL completion or semantic validation, save update or failure, implemented permission changes, or Nitro execution. Controlled saturation, workload admission, query-worker scale-out, safe scale-in, managed logical-compute lifecycle, HMS scaling, metadata-database connection saturation, failover, backup restore, and storage exhaustion also remain untested.

Classic was observed working in realm gj76anadpsc, workspace w-t5e2kcxjd, for the tested admin scope and is documented as Available for that scope. Assessment coverage is partial, and behavior outside that scope was not tested.