update flink statement warnings UI based on new response structure#3254
update flink statement warnings UI based on new response structure#3254Noel Cothren (noeldevelops) merged 24 commits intomainfrom
Conversation
741864d to
99f59ae
Compare
4660052 to
22ba7e8
Compare
There was a problem hiding this comment.
Pull request overview
Updates the Flink Statement Results webview to surface statement warnings using the new structured warnings field from the getSqlv1Statement response, while remaining backward compatible with legacy [Warning] text embedded in status.detail.
Changes:
- Add warning parsing utilities to prefer structured API warnings and fall back to legacy
[Warning]parsing. - Extend statement models/results manager/webview view model to pass warnings through to the results viewer.
- Refactor results viewer “details/warnings” header UI into a unified list with updated HTML/CSS rendering.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| src/webview/flink-statement-results.ts | Builds a unified detailItems list combining error/info detail text with structured/legacy warnings. |
| src/webview/flink-statement-results.html | Reworks the header details UI to render multiple detail items with severity styling. |
| src/models/flinkStatement.ts | Adds a warnings getter that extracts structured warnings or parses legacy detail warnings. |
| src/flinkSql/warningParser.ts | New helper module to parse legacy warnings, prefer structured warnings, and strip [Warning] blocks from detail. |
| src/flinkSql/warningParser.test.ts | Unit tests for warning parsing/extraction/stripping behavior. |
| src/flinkSql/flinkStatementResultsManager.ts | Includes statement warnings in the data returned to the webview. |
| src/flinkSql/flinkStatementResultsManager.test.ts | Updates expected statement meta to include warnings. |
You can also share your feedback on Copilot code review. Take the survey.
|
Clarifies that the type assertion should be removed once the OpenAPI spec includes the warnings field on statement status. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Remove hasWarnings, hasCriticalWarnings, and formattedWarnings signals that were not referenced in the template or elsewhere. Inline the formatting logic directly into the detailItems derivation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Merge identical .detail-item.error/.detail-item.critical and .detail-severity.error/.detail-severity.critical rules into combined selectors. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
detailText was only consumed by detailItems, making it an unnecessary intermediate signal. Inline the logic to simplify the reactive graph. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ection Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ate format - Remove .replace(/\n/g, "<br>") since data-text + pre-wrap handles newlines - Extract duplicated legacy warning regex into shared LEGACY_WARNING_PATTERN - Use .toLocaleString() instead of String() for warning timestamps Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ab708d6 to
83b6e36
Compare
Dave Shoup (shouples)
left a comment
There was a problem hiding this comment.
LGTM and works well from what I was able to clicktest in our various environments, just one minor question but shouldn't block merging
| /** API warning shape from the new structured warnings field */ | ||
| export interface StatementWarning { | ||
| readonly severity: string; | ||
| readonly created_at: Date | null; | ||
| readonly reason: string; | ||
| readonly message: string; | ||
| } |
There was a problem hiding this comment.
Any reason we don't use SqlV1StatementWarning directly? Looks like the only difference is some of these values are set as readonly but I don't think any call points try to mutate these properties after we get the response back
There was a problem hiding this comment.
ah good catch. I'm updating now to use the client type. created_at is the only thing that needs a little fix, incoming...
update date null handling to work
f050c09
|


Summary of Changes
Click-testing instructions
Changes are visible in the VS Code Flink Statement Results viewer when there are Statement Details, Errors, or Warnings. The new API is under a feature flag, so requires internal access to our Staging environment where the flag is enabled. There are detailed testing scenarios for the internal team in shared docs.
flink-statement-results.tsfile, setthis.hasWarningsto true & add an array of mocks e.g.Optional: Any additional details or context that should be provided?
Pull request checklist
Please check if your PR fulfills the following (if applicable):
Tests
Release notes