[Pika-Yalei]

Summary

Opening table details could mark a healthy SQL workspace connection as failed, hiding the object list and disabling query actions. Keep the connection in the connected state after a successful metadata response, while preserving failure handling and stale-response guards. Add a reusable browser regression scenario.

Release packages could also fail during Spring Boot logging initialization because DashScope SDK transitively introduced slf4j-simple alongside Logback. Exclude that provider at the SDK dependency, switch the build-time driver bundler to Logback, and configure its root log level as INFO. This removes the competing provider from application runtime dependencies and distributions without requiring a JVM provider override.

Related Issues

None.

Test Plan (Required)

• Not tested (explain why below)
• Unit tests
• Integration tests
• Frontend lint / build
• Backend build
• Manual verification

Details:

• cd frontend && npm run lint -- --no-fix passed.
• cd package && ./all_build.sh web passed.
• An isolated method-level harness reproduced the table-details regression and passed seven checks covering successful metadata reads, API/transport failures, late responses after disconnect/reconnect/tab changes, and recovery from an unblocked failed state.
• In the built-in browser against a local ClickHouse fixture, single clicks, repeated double-clicks, reconnecting, and refreshing kept the object list visible and query actions enabled. Generated SQL was not executed.
• cd package && ./package.sh --build passed and generated all three installation archives. Frontend resources were additionally rebuilt with Node.js 22.22.1 and the archives regenerated successfully.
• Inspected SLF4J service registrations across eight boot/package runtime configurations: each contained only the Logback provider.
• Scanned the actual alone, console, and sidecar archives: application libraries contained one Logback provider, no slf4j-simple, and no legacy SLF4J binding. A JVM probe using each archive's libraries selected LoggerContext and passed Spring Boot logging initialization without a provider override.
• A JVM probe of the driver bundler's runtime classpath confirmed Logback and an INFO root log level.
• Restarted the local IDEA backend and confirmed FULL-mode startup, embedded worker readiness, a successful health check, and SQL workspace loading without browser console errors.
• Browser-level database outage and delayed-network injection were not performed; those failure and race paths were checked by the isolated harness. The archives were checked with logging initialization probes rather than full isolated server deployments.

Checklist

• The PR title clearly describes the change.
• The change follows the repository coding standards.
• Documentation was updated when behavior or usage changed.
• Tests were added or updated for behavior changes (reusable browser regression procedure).
• Generated files, dependency directories, logs, and local build artifacts are not included.

[hellojuantu]

Great！