Use vscode:// deep links for session URLs in VS Code - #194
Merged
Merged
Conversation
When running inside VS Code, session detail links now point to the googlecloudtools.datacloud extension's session view instead of the Cloud Console, for the session-creation message, existing-session reattach message, and the notebook repr's session link.
Contributor
There was a problem hiding this comment.
Code Review
This pull request introduces a helper function _build_session_details_url to dynamically generate VS Code-specific session URLs when running in a VS Code environment, updating several display and print locations to use this helper. Unit tests are also added to verify this behavior. The feedback suggests updating the type hints of the helper's parameters to Optional[str] to prevent static analysis errors, and registering cleanups for mock.patch.dict calls in the unit tests to avoid test environment pollution.
ajma
commented
Sep 10, 2026
Address review feedback: the url was being assembled partly in _repr_html_ and partly inline in the <a href>; build it in full where the other session-related urls are constructed.
region and project_id are always passed self._region/self._project_id, which are Optional[str] until a session connects.
ajma
commented
Sep 10, 2026
dborowitz
reviewed
Sep 10, 2026
The vscode:// deep link only resolves if googlecloudtools.datacloud is installed; otherwise VS Code shows a generic, confusing error. Check via `code --list-extensions` and fall back to the Cloud Console url when it's not present or the check can't run.
ajma
force-pushed
the
worktree-vscode-session-links
branch
from
September 10, 2026 21:58
48d68a3 to
728f341
Compare
code may not be on PATH even when VS Code and the extension are installed (e.g. macOS before running "Shell Command: Install 'code' command in PATH", or a remote/SSH session using .vscode-server). Scan the on-disk extensions directories as a fallback so the vscode:// link still shows up in those cases.
On a remote backend, code runs through a client-forwarding shim whose --list-extensions behavior isn't reliable, so only the on-disk ~/.vscode-server/extensions scan is trusted there.
Reliably detecting whether the Data Analytics Kit extension is installed proved impractical across local VS Code, Remote-SSH, and forks. Simplify by always showing both the Cloud Console link and the vscode:// deep link whenever running inside VS Code, and let the extension's own URI handler be the point of failure if it's missing.
Rename the link labels to "Managed Spark Session (Cloud Console)" and "Managed Spark Session (Data Agent Kit)" so it's clear which link goes where.
medb
approved these changes
Sep 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
VSCODE_PIDset), session detail messages/links now show both a Cloud Console link and avscode://googlecloudtools.datacloud/dataproc/sessions/<id>?project=<project>&location=<region>deep link, instead of trying to detect which one to show.code --list-extensionsisn't always on PATH, its behavior is unreliable when forwarded through the Remote-SSH shim, extensions directories differ across forks/code-server, and even a correct disk scan can't confirm client-side installation state from a remote backend. Rather than chase that, we just always show both links and let the extension's own URI handler be the point of failure if it's missing..../dataproc/interactive/{region}/{session_id}?project={project_id}URL shape: the new-session-created message, the reattach-to-existing-session message, and the notebook_repr_html_(which now shows both session links plus "Spark UI").Test plan
_display_session_link_on_creation,_get_exiting_active_session, and_repr_html_asserting both links are present when in VS Code, and a test confirming no vscode link when not.uv run pyink --checkclean on all changed files.uv run pytest tests/unit/— 165 passed, 1 pre-existing unrelated failure (test_create_session_without_application_default_credentials, fails identically onmain).