cluster-ui: database pages should handle partially erroneous responses #102386

THardy98 · 2023-04-26T22:27:16Z

Related to: #102204

Describe the problem

Currently, the databases pages (databases & tables) do not handle partially erroneous response payloads gracefully. If any statement in the request encounters an error, the entire page will display an error.

Instead, the page should be able to render the statements in the request that succeed and notify the user for the portions of the page that do not.

Jira issue: CRDB-27420

Part of: cockroachdb#102386 This change introduces a `separate_txns` field to the sql api endpoint. This field allows callers to run provided statements in separate transactions. Failures in separate transactions are scoped to their respective transaction and do not interfere with the execution of subsequent transactions. The exception to this case is if the max response size is exceeded. If the response size is exceeded in an earlier transaction, it will still exceed the limit in subsequent transactions. The response-level error using `separate_txns` is a generic message: `separate transaction payload encountered transaction error(s)`, indicating that an error has occurred in at least one of the transactions. Release note: None

Part of: cockroachdb#102386 This change introduces a `separate_txns` field to the sql api endpoint. This field allows callers to run provided statements in separate transactions. Failures in separate transactions are scoped to their respective transaction and do not interfere with the execution of subsequent transactions. The exception to this case is if the max response size is exceeded. If the response size is exceeded in an earlier transaction, it will still exceed the limit in subsequent transactions. The response-level error using `separate_txns` is a generic message: `separate transaction payload encountered transaction error(s)`, indicating that an error has occurred in at least one of the transactions. We additionally add a `stop_on_error` field to allow callers to stop execution of subsequent txns (i.e. in the case where `separate_txns` is true). Release note: None

108447: server: support separate transactions on sql api r=THardy98 a=THardy98 Part of: #102386 This change introduces a `separate_txns` field to the sql api endpoint. This field allows callers to run provided statements in separate transactions. Failures in separate transactions are scoped to their respective transaction and do not interfere with the execution of subsequent transactions. The exception to this case is if the max response size is exceeded. If the response size is exceeded in an earlier transaction, it will still exceed the limit in subsequent transactions. The response-level error using `separate_txns` is a generic message: `separate transaction payload encountered transaction error(s)`, indicating that an error has occurred in at least one of the transactions. We additionally add a `stop_on_error` field to allow callers to stop execution of subsequent txns (i.e. in the case where `separate_txns` is true). Release note: None Co-authored-by: Thomas Hardy <[email protected]>

Part of: #102386 This change introduces a `separate_txns` field to the sql api endpoint. This field allows callers to run provided statements in separate transactions. Failures in separate transactions are scoped to their respective transaction and do not interfere with the execution of subsequent transactions. The exception to this case is if the max response size is exceeded. If the response size is exceeded in an earlier transaction, it will still exceed the limit in subsequent transactions. The response-level error using `separate_txns` is a generic message: `separate transaction payload encountered transaction error(s)`, indicating that an error has occurred in at least one of the transactions. We additionally add a `stop_on_error` field to allow callers to stop execution of subsequent txns (i.e. in the case where `separate_txns` is true). Release note: None

Part of: cockroachdb#102386 Prior to this change, any query error in the reponse payload for the databases page would cause the page to render an error. This was problematic as some queries used to power the databases page directly query `system` tables, meaning only `ADMIN` users could access the page. This change allows the databases page to handle network responses with query errors, consequently allowing non-admin users to view the data they are privy to. On the databases page, two types of requests are made: - a single request to fetch all database names - a request to fetch the database details for each database name The error handling for these requests has changed as such: - if we encounter a network or a non size-related query error when requesting database names, render a page error - if we encounter a 'max size' query error when requesting database names, render an alert that we're showing partial results - if we encounter any error requesting a database's details, render a `Caution` icon next to the database's name to indicate there was an issue getting results, the `Caution` icon has a tooltip providing a general explanation as to what the issue is - network errors when fetching database details provide no data for the database's table row, consequently the row of statistics for that database is `unavailable`, the network error message is provided in the `Caution` icon tooltip - query errors when fetching database details are scoped to the row cells for that query, which are `unavailable` - `unavailable` cells have a tooltip that highlight the error for that cell as well Release note (ui change): Allow non-admin users to view the databases page.

Part of: cockroachdb#102386 This change applies the same error handling ideas from cockroachdb#109245 to the database table page, enabling non-admin users to use the database table page and providing better transparency to data fetching issues. `unavailable` fields provide a tooltip that displays the error impacting that field. Release note (ui change): Non-admin users are able to use the database table page.

Part of: cockroachdb#102386 Prior to this change, any query error in the reponse payload for the databases page would cause the page to render an error. This was problematic as some queries used to power the databases page directly query `system` tables, meaning only `ADMIN` users could access the page. This change allows the databases page to handle network responses with query errors, consequently allowing non-admin users to view the data they are privy to. On the databases page, two types of requests are made: - a single request to fetch all database names - a request to fetch the database details for each database name The error handling for these requests has changed as such: - if we encounter a network or a non size-related query error when requesting database names, render a page error - if we encounter a 'max size' query error when requesting database names, render an alert that we're showing partial results - if we encounter any error requesting a database's details, render a `Caution` icon next to the database's name to indicate there was an issue getting results, the `Caution` icon has a tooltip providing a general explanation as to what the issue is - network errors when fetching database details provide no data for the database's table row, consequently the row of statistics for that database is `unavailable`, the network error message is provided in the `Caution` icon tooltip - query errors when fetching database details are scoped to the row cells for that query, which are `unavailable` - `unavailable` cells have a tooltip that highlight the error for that cell as well Release note (ui change): Allow non-admin users to view the databases page.

109245: cluster-ui: handle partial response errors on the databases page r=THardy98 a=THardy98 Part of: #102386 **Demos** (Note: these demos show this same logic applied to both the database details and database table pages as well): DB-Console - https://www.loom.com/share/5108dd655ad342f28323e72eaf68219c - https://www.loom.com/share/1973383dacd7494a84e10bf39e5b85a3 Prior to this change, any query error in the reponse payload for the databases page would cause the page to render an error. This was problematic as some queries used to power the databases page directly query `system` tables, meaning only `ADMIN` users could access the page. This change allows the databases page to handle network responses with query errors, consequently allowing non-admin users to view the data they are privy to. On the databases page, two types of requests are made: - a single request to fetch all database names - a request to fetch the database details for each database name The error handling for these requests has changed as such: - if we encounter a network or a non size-related query error when requesting database names, render a page error - if we encounter a 'max size' query error when requesting database names, render an alert that we're showing partial results - if we encounter any error requesting a database's details, render a `Caution` icon next to the database's name to indicate there was an issue getting results, the `Caution` icon has a tooltip providing a general explanation as to what the issue is - network errors when fetching database details provide no data for the database's table row, consequently the row of statistics for that database is `unavailable`, the network error message is provided in the `Caution` icon tooltip - query errors when fetching database details are scoped to the row cells for that query, which are `unavailable` - `unavailable` cells have a tooltip that highlight the error for that cell as well **Note**: the change in `planner.go` allows users to see span statistics for any table, not just tables a user has `SELECT` privileges for. This is particularly useful for the databases page where users need to see the span statistics for a database, but only have `SELECT` privileges on a subset of tables. Regardless, span statistics are gated by `VIEWACTIVITY`, not `SELECT` privileges. Release note (ui change): Allow non-admin users to view the databases page. 109438: roachprod: azure gc cleans up empty clusters r=renatolabs a=DarrylWong Azure allows for clusters to exist with no attached VM, which roachprod assumes is not possible. This would occur if azure.create failed after creating a resource group but before creating a VM. Roachprod GC only searches for VMs when searching for clusters, so these VM-less clusters would never be found and cleaned up. This change adds the ability to list empty clusters by querying resource groups instead of VMs. This is used by GC and destroy jobs to correctly identify and cleanup these dangling resources. Epic: https://cockroachlabs.atlassian.net/browse/CRDB-3373 Release note: None 109652: sql: refactor global privilege and legacy role option checking r=rafiss a=andyyang890 This patch abstracts the logic for checking whether a user has a global (system) privilege or the corresponding legacy role option into a new function (`HasGlobalPrivilegeOrRoleOption`). It also adds a wrapper function that returns an insufficient privileges error when the user has neither the privilege nor the legacy role option (`CheckGlobalPrivilegeOrRoleOption`). Informs #103237 Release note: None Co-authored-by: Thomas Hardy <[email protected]> Co-authored-by: DarrylWong <[email protected]> Co-authored-by: Andy Yang <[email protected]>

Part of: cockroachdb#102386 This change applies the same error handling ideas from cockroachdb#109245 to the database details page, enabling non-admin users to use the database details page and providing better transparency to data fetching issues. Errors encountered while fetching table details can be viewed via the tooltip provided by the `Caution` icon at the table's name. `unavailable` cells also provide a tooltip that displays the error impacting that exact cell. Release note (ui change): Non-admin users are able to use the database details page.

Part of: cockroachdb#102386 Prior to this change, any query error in the reponse payload for the databases page would cause the page to render an error. This was problematic as some queries used to power the databases page directly query `system` tables, meaning only `ADMIN` users could access the page. This change allows the databases page to handle network responses with query errors, consequently allowing non-admin users to view the data they are privy to. On the databases page, two types of requests are made: - a single request to fetch all database names - a request to fetch the database details for each database name The error handling for these requests has changed as such: - if we encounter a network or a non size-related query error when requesting database names, render a page error - if we encounter a 'max size' query error when requesting database names, render an alert that we're showing partial results - if we encounter any error requesting a database's details, render a `Caution` icon next to the database's name to indicate there was an issue getting results, the `Caution` icon has a tooltip providing a general explanation as to what the issue is - network errors when fetching database details provide no data for the database's table row, consequently the row of statistics for that database is `unavailable`, the network error message is provided in the `Caution` icon tooltip - query errors when fetching database details are scoped to the row cells for that query, which are `unavailable` - `unavailable` cells have a tooltip that highlight the error for that cell as well Release note (ui change): Allow non-admin users to view the databases page.

108175: kvserver: unskip lease preferences during outage r=andrewbaptist a=kvoli Previously, `TestLeasePreferenceDuringOutage` would force replication queue processing of the test range, then assert that the range up-replicated and lease transferred to a preferred locality. This test was skipped, and two of the assumptions it relied on to pass were no longer true. After #85219, the replicate queue no longer re-processes replicas. Instead, the queue requeues replicas after processing, at the appropriate priority. This broke the test due to the replicate queue being disabled, making the re-queue a no-op. After #94023, the replicate queue no longer looked for lease transfers, after processing a replication action. Combined with #85219, the queue would now be guaranteed to not process both up-replication and lease transfers from a single enqueue. Update the test to not require a manual process, instead using a queue range filter, which allows tests which disable automatic replication, to still process filtered ranges via the various replica queues. Also, ensure that the non-stopped stores are considered live targets, after simulating an outage (bumping manual clocks, stopping servers) -- so that the expected up-replication, then lease transfer can proceed. Fixes: #88769 Release note: None 109432: cluster-ui: handle partial response errors on the database details page r=THardy98 a=THardy98 Part of: #102386 **Demos** (Note: these demos show this same logic applied to both the databases and database table pages as well): DB-Console - https://www.loom.com/share/5108dd655ad342f28323e72eaf68219c - https://www.loom.com/share/1973383dacd7494a84e10bf39e5b85a3 This change applies the same error handling ideas from #109245 to the database details page, enabling non-admin users to use the database details page and providing better transparency to data fetching issues. Errors encountered while fetching table details can be viewed via the tooltip provided by the `Caution` icon at the table's name. `unavailable` cells also provide a tooltip that displays the error impacting that exact cell. Release note (ui change): Non-admin users are able to use the database details page. 110292: c2c: use seperate spanConfigEventStreamSpec in the span config event stream r=stevendanna a=msbutler Previously, the spanConfigEventStream used a streamPartitionSpec, which contained a bunch of fields unecessary for span config streaming. This patch creates a new spanConfigEventStreamSpec which contains the fields only necessary for span config event streaming. Informs #109059 Release note: None 110309: teamcity-trigger: ensure that `race` tag is only passed once r=healthy-pod a=healthy-pod By running under `-race`, the go command defines the `race` build tag for us [1]. Previously, we defined it under `TAGS` to let the issue poster know that this is a failure under `race` and indicate that in the issue. At the time, defining the tag twice didn't cause issues but after #109773, it led to build failures [2]. To reproduce locally: ``` bazel test -s --config=race pkg/util/ctxgroup:all --test_env=GOTRACEBACK=all --define gotags=bazel,gss,race ``` As a follow-up, we should find another way to let the issue poster know that a failure was running under `race`. [1] https://go.dev/doc/articles/race_detector#Excluding_Tests [2] #109994 (comment) Epic: none Release note: None Co-authored-by: Austen McClernon <[email protected]> Co-authored-by: Thomas Hardy <[email protected]> Co-authored-by: Michael Butler <[email protected]> Co-authored-by: healthy-pod <[email protected]>

Part of: #102386 This change applies the same error handling ideas from #109245 to the database details page, enabling non-admin users to use the database details page and providing better transparency to data fetching issues. Errors encountered while fetching table details can be viewed via the tooltip provided by the `Caution` icon at the table's name. `unavailable` cells also provide a tooltip that displays the error impacting that exact cell. Release note (ui change): Non-admin users are able to use the database details page.

Part of: cockroachdb#102386 This change applies the same error handling ideas from cockroachdb#109245 to the database details page, enabling non-admin users to use the database details page and providing better transparency to data fetching issues. Errors encountered while fetching table details can be viewed via the tooltip provided by the `Caution` icon at the table's name. `unavailable` cells also provide a tooltip that displays the error impacting that exact cell. Release note (ui change): Non-admin users are able to use the database details page.

Part of: cockroachdb#102386 This change applies the same error handling ideas from cockroachdb#109245 to the database table page, enabling non-admin users to use the database table page and providing better transparency to data fetching issues. `unavailable` fields provide a tooltip that displays the error impacting that field. Release note (ui change): Non-admin users are able to use the database table page.

109521: cluster-ui: handle partial response errors on the database table page r=THardy98 a=THardy98 Part of: #102386 **Demos** (Note: these demos show this same logic applied to both the databases and database details pages as well): DB-Console - https://www.loom.com/share/5108dd655ad342f28323e72eaf68219c - https://www.loom.com/share/1973383dacd7494a84e10bf39e5b85a3 This change applies the same error handling ideas from #109245 to the database table page, enabling non-admin users to use the database table page and providing better transparency to data fetching issues. `unavailable` fields provide a tooltip that displays the error impacting that field. Release note (ui change): Non-admin users are able to use the database table page. 109788: docs-issue-generation: Create docs issues in Jira r=nickvigilante a=nickvigilante Fixes DOC-7066 Additional fixes: - Update the authorization scheme for GitHub to `Bearer` - Divide `docs_issue_generation.go` into logical package files Release note: None 110288: roachtest: codify longer ttl external storage buckets r=renatolabs a=msbutler Previously, the only codified external buckets for roachtests to back up to was the `cockroachdb-backup-testing` buckets in s3 and gcs which each had a ttl of 1 day. This low ttl is not suitable for roachtests that produce backups that the test failure investigator may want to inspect. This patch codifies the new `cockroachdb-backup-testing-long-ttl` buckets in s3 and gcs, which currently have a ttl of 20 days, the same ttl that team city artifacts have. This patch also points the c2c, backup-restore/mixed-version, and disagg-rebalance roachtests to use these new buckets. Note this PR only points roachtests that run in public TC environments to the new buckets. A future PR will set the BACKUP_TESTING_BUCKET_LONG_TTL env var for private roacttests to a new bucket with a longer ttl. Epic: none Release note: none 110610: parser/backup: fix normalization of detached = false r=dt a=dt Release note: none. Epic: none. 110638: roachtest: add c2c/multiregion/SameRegions/kv0 roachtest r=stevendanna a=msbutler This patch adds a new c2c roachtest that spins up multiregion source and destination clusters, constrains the kv database to the us-east1-b region, and asserts that the replicated span configuration enforces the regional constraint on the destination cluster during replication. Informs #109059 Release note: None Co-authored-by: Thomas Hardy <[email protected]> Co-authored-by: Nick Vigilante <[email protected]> Co-authored-by: Michael Butler <[email protected]> Co-authored-by: David Taylor <[email protected]>

Part of: cockroachdb#102386 This change applies the same error handling ideas from cockroachdb#109245 to the database table page, enabling non-admin users to use the database table page and providing better transparency to data fetching issues. `unavailable` fields provide a tooltip that displays the error impacting that field. Release note (ui change): Non-admin users are able to use the database table page.

THardy98 · 2023-09-18T15:04:37Z

Below are PRs that handle partially erroneous responses on db pages, allowing users with restricted permissions to still view the db pages:

Databases Page Improvement: #109245
Database Detail Page Improvement: #109432
Table Detail Page Improvement (database table page - specifically relevant to this issue): #109521

THardy98 added C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. T-cluster-observability labels Apr 26, 2023

THardy98 self-assigned this May 9, 2023

THardy98 mentioned this issue Aug 9, 2023

server: support separate transactions on sql api #108447

Merged

blathers-crl bot mentioned this issue Aug 16, 2023

release-23.1: server: support separate transactions on sql api #108849

Merged

THardy98 mentioned this issue Aug 22, 2023

cluster-ui: handle partial response errors on the databases page #109245

Merged

THardy98 mentioned this issue Aug 25, 2023

cluster-ui: handle partial response errors on the database table page #109521

Merged

THardy98 mentioned this issue Sep 11, 2023

release-23.1: cluster-ui: handle partial response errors on the databases page #110342

Merged

blathers-crl bot mentioned this issue Sep 11, 2023

release-23.1: cluster-ui: handle partial response errors on the database details page #110360

Closed

THardy98 mentioned this issue Sep 11, 2023

release-23.1: cluster-ui: handle partial response errors on the database details page #110369

Merged

THardy98 mentioned this issue Sep 14, 2023

release-23.1: cluster-ui: handle partial response errors on the database table page #110680

Merged

THardy98 closed this as completed Sep 18, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cluster-ui: database pages should handle partially erroneous responses #102386

cluster-ui: database pages should handle partially erroneous responses #102386

THardy98 commented Apr 26, 2023 •

edited by cockroach-jira-scripts

Loading

THardy98 commented Sep 18, 2023

cluster-ui: database pages should handle partially erroneous responses #102386

cluster-ui: database pages should handle partially erroneous responses #102386

Comments

THardy98 commented Apr 26, 2023 • edited by cockroach-jira-scripts Loading

THardy98 commented Sep 18, 2023

THardy98 commented Apr 26, 2023 •

edited by cockroach-jira-scripts

Loading