Skip to content

fix(workbench): reactivate Positron console tab before concluding no console#521

Merged
samcofer merged 1 commit into
mainfrom
fix/positron-console-reactivate
Jul 23, 2026
Merged

fix(workbench): reactivate Positron console tab before concluding no console#521
samcofer merged 1 commit into
mainfrom
fix/positron-console-reactivate

Conversation

@zachhannum

Copy link
Copy Markdown
Contributor

Summary

Follow-up to #509. After that merged (VIP 0.56.0), the Workbench daily VIP verification's preview leg passes, but the GA release leg still fails test_clone_positron, now with:

terminal_run timed out after 120000ms waiting for done marker in '/tmp/vip_term_....txt'

Reproduced against the exact failing image (ghcr.io/posit-dev/workbench:2026.07.1-147.pro6, GA) and root-caused it as a distinct, build-specific race.

Root cause

terminal_run runs the clone in the Positron Terminal, then reads the result back via the Positron Console. On the GA build (2026.07.1), selecting the Terminal tab removes .positron-console from the DOM. When the console readback then calls ensure_positron_console, it sees no console panel — and because a console session already exists, the "Start New Console Session" button is also gone — so it returns False, surfacing as No Positron console could be started (no R/Python interpreter resolved). Every readback retry hits the same state, so terminal_run exhausts its budget and times out.

It's intermittent (depends on whether the Terminal held focus at readback time) and hit the GA image far more often (~1-in-3) than the daily/preview build, which is why #509 looked green on preview but the release leg kept failing. The console and interpreter are fine — the captured console showed R 4.6.1 started. — VIP just failed to find the backgrounded console.

Fix

ensure_positron_console now activates the Console tab and briefly polls for .positron-console to re-render before falling through to the start-a-new-console path, so an existing (backgrounded) console is detected instead of being missed. The reactivation poll draws from the same shared timeout budget, so the total wait stays bounded (the existing self-test for that invariant still holds).

Testing

  • Reproduced the failure on the GA arm64 image, then verified the fix: test_clone_positron passed 12/12 (previously ~1-in-3 failed), alongside test_clone_rstudio, test_clone_vscode, and test_launch_positron.
  • selftests/test_workbench_exec.py: 76 passed. ruff check / format --check clean.

…console

On Workbench 2026.07.1 (GA), running a command in the Positron Terminal (as
terminal_run does before its console readback) removes .positron-console from
the DOM while the Terminal tab is focused. ensure_positron_console then saw no
console panel, and because a console session already exists its "Start New
Console Session" button is also gone, so it returned False -- surfacing as
"No Positron console could be started (no R/Python interpreter resolved)" and a
terminal_run 120s timeout on every retry. This was intermittent (it depends on
whether the Terminal held focus at readback time) and hit the GA image far more
often than the daily/preview build.

ensure_positron_console now activates the Console tab and briefly polls for the
panel to re-render before falling through to the start-a-new-console path, so an
existing (backgrounded) console is detected instead of being missed. The poll
draws from the same shared timeout budget, so the total wait stays bounded.

Verified against ghcr.io/posit-dev/workbench:2026.07.1-147.pro6 (GA, arm64):
test_clone_positron passed 12/12 (previously ~1-in-3 failed), alongside
test_clone_rstudio, test_clone_vscode and test_launch_positron.
Copilot AI review requested due to automatic review settings July 22, 2026 14:08

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR improves the reliability of Positron console readback in Workbench GA builds by ensuring VIP re-activates the Console tab and briefly polls for the console panel to re-render before concluding that no console exists. This addresses a build-specific DOM behavior where selecting the Terminal tab can unmount the console panel, causing terminal_run readback to repeatedly fail and eventually time out.

Changes:

  • Add a small “reactivation” polling phase in ensure_positron_console after activating the Console tab to detect an already-running (but backgrounded) console.
  • Introduce _POSITRON_REACTIVATE_POLLS and share the existing timeout budget across the new phase and the existing start/discovery/render phases.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +320 to +324
reactivate = min(remaining, _POSITRON_REACTIVATE_POLLS)
while reactivate > 0:
if page.locator(PositronSession.CONSOLE_PANEL).count() > 0:
return True
page.wait_for_timeout(_POSITRON_POLL_MS)
@samcofer
samcofer merged commit 6862078 into main Jul 23, 2026
36 checks passed
@samcofer
samcofer deleted the fix/positron-console-reactivate branch July 23, 2026 21:11
@github-actions

Copy link
Copy Markdown
PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-07-23 21:11 UTC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants