Fixed Issues
Cloudera AI Workbench
2.0.55-h2000-b10, Cloudera AI Registry
1.16.0-h2000-b5, and Cloudera AI Inference service
1.13.0-h2000-b17 provide resolutions for identified bugs.
Cloudera AI Workbench
- DSE-58549: Job dependency graph rendering failure with large job counts
The Job Dependencies graph on a job's page failed to render in projects containing more than 10 jobs. This issue is now resolved. The dependency graph correctly renders the full dependency chain for projects containing up to 200 jobs. Additionally, node status colors (green for success, red for failure) now display accurately.
-
DSE-57745: Stale Istio VirtualService routing rules remaining after changing application subdomains
When changing an application subdomain on an Istio Ingress-enabled workbench, stale VirtualService objects were not automatically cleaned up. This prevented the old subdomain from being reused and caused requests to the old URL to return a 503 cluster_not_found error instead of a 404 error. This issue is now resolved. Stale routing resources are automatically garbage-collected within approximately 5 minutes of a subdomain change.
-
DSE-58565: PBJ Workbench session freeze during high-volume output streaming
Running commands that generate high-volume output (such as printing hundreds of thousands of lines) in a PBJ Workbench session caused the session to freeze, drop the LiveLog WebSocket connection, and stop running subsequent commands. This issue is now resolved. The session output pipeline now coalesces and size-caps output delivery to maintain session responsiveness. Additionally, if output exceeds the MAX_TEXT_LENGTH limit (default 800,000 characters), a "Truncating text…" notice is visibly displayed.
-
DSE-57701: PBJ Workbench sessions freezing after LiveLog WebSocket disconnection
PBJ Workbench sessions permanently froze following a LiveLog WebSocket disconnection, such as those triggered by idle timeouts, network interruptions, or pod restarts. Although the status bar displayed a green, connected state after reconnecting, commands failed to run and returned no output. This issue is now resolved. The LiveLog client automatically resubscribes to all active streams upon reconnecting, allowing sessions to recover smoothly without requiring a manual restart.
-
DSE-58651: SSO/SAML access loss following in-place workbench upgrades
Workbenches that underwent a side-by-side upgrade followed by a subsequent in-place upgrade experienced SSO access loss. The workload access groups in the SAML configuration were incorrectly regenerated, creating new UMS groups to which existing users were not assigned. This issue is now resolved. The upgrade process now preserves the original workspace identity when regenerating SAML configurations, preventing access disruptions
-
DSE-58422: Data connection and PySpark session failures following workbench upgrade
After upgrading a workbench, the workbench failed to connect to the base cluster, preventing base cluster configurations from mounting and causing data connections and PySpark sessions to fail. This issue is now resolved. The upgrade workflow now correctly maintains the necessary base cluster configurations to ensure data connections and PySpark sessions function as expected.
-
DSE-58563: LiveLog cleanup failure on Istio-enabled workbenches
On Istio-enabled Cloudera AI Workbench, the automated livelog-cleaner job failed to delete old LiveLog topics because DELETE requests were blocked by the Istio AuthorizationPolicy with an HTTP 403 error. Additionally, a secondary issue caused failed cleanup attempts to be incorrectly marked as completed, skipping them in future cycles and eventually leading to exhausted PVC capacity and "No space left on device" errors. This issue is now resolved. The authorization policy is updated to allow the sa-cdsw-livelog-cleaner service account, ensuring LiveLog storage is cleaned up properly.
-
DSE-58500: Project or application deletion failure due to foreign key violation
Deleting a project or application failed with a foreign key violation error if the project contained related entries in the internal retry workloads table. This issue is now resolved. The database schema correctly cascades deletions, allowing projects and applications to be deleted without errors.
