fix(e2e): drive run_dbconnect notebook cells explicitly after the kernel is bound#2014
Draft
rugpanov wants to merge 1 commit into
Draft
fix(e2e): drive run_dbconnect notebook cells explicitly after the kernel is bound#2014rugpanov wants to merge 1 commit into
rugpanov wants to merge 1 commit into
Conversation
Contributor
Author
|
🤖 Integration tests triggered for |
rugpanov
force-pushed
the
fix/run-dbconnect-progress-bar-stall
branch
from
13f9832 to
5128b57
Compare
Contributor
Author
|
🤖 Integration tests ❌ 5 of 35 test jobs failed for |
Contributor
Author
|
🤖 Integration tests ❌ 7 of 35 test jobs failed for |
rugpanov
force-pushed
the
fix/run-dbconnect-progress-bar-stall
branch
from
baefbfb to
510d98b
Compare
rugpanov
changed the title
Contributor
Author
|
🤖 Integration tests ❌ 7 of 35 test jobs failed for |
…is bound
*Why*
The run_dbconnect notebook (`.ipynb`) and magic (`.py` Databricks notebook)
tests are flaky: "Run All" / "Jupyter: Run All Cells" runs the first DBConnect
cell but does not advance to the rest in the headless CI harness, so later
cells stay `<not run>` and the expected `*-output.json` files are never
written. A manual repro on a real machine confirmed this is a webdriver/xvfb
artifact — a real user's Run All runs every cell, and running the cells
one-by-one through the kernel also works. So the fix stays in the test and
keeps execution going through VS Code (real kernel + the extension's injected
spark/%sql/_sqldf/%run magics).
Two earlier attempts failed for reasons now understood from the VS Code source
(coreActions.ts / executeActions.ts):
- Executing a cell before a kernel was bound popped a modal kernel picker
that hung the executeWorkbench promise ("Remote command timeout exceeded").
- Targeting cells via `window.activeNotebookEditor` silently no-ops for the
Interactive Window (the focused editor is the `.py` text editor, not the
IW), and passing a mismatched `document` makes `notebook.cell.execute`
resolve no editor and return without running anything (no throw).
*What*
- Replace the per-cell helpers with `runNotebookCellsByUri(uriMatch)`, which:
- looks the notebook up in `vscode.workspace.notebookDocuments` (by URI
substring, or `notebookType === "interactive"` for the IW), so it works for
both the `.ipynb` editor and the Interactive Window;
- runs each not-yet-executed code cell via `notebook.cell.execute` with
`document: doc.uri` (URI-based resolution, independent of focus);
- logs which cells it dispatched and throws a precise error if the notebook
isn't found — so a no-op surfaces here, not later as a missing-file timeout.
- Notebook test: keep `Notebook: Run All` (binds kernel + runs cell 0), wait for
cell 0's output, then `runNotebookCellsByUri("notebook.ipynb")`.
- Magic test: keep `Jupyter: Run All Cells` (creates IW + binds kernel), wait
until the interactive doc's first cell has an executionOrder, then
`runNotebookCellsByUri("interactive")`, then assert both `%sql`->`_sqldf` and
`%run` outputs.
- Callbacks kept inline-arrow-only (no esbuild `__name` wrapper).
*Verification*
- `tsc --noEmit -p src/test/e2e/tsconfig.json`: 0 errors; eslint + prettier: clean.
- esbuild+keepNames transpile: 0 `__name` occurrences in the callbacks.
- Command contract confirmed against microsoft/vscode source (parseMultiCellExecutionArgs,
getEditorFromArgsOrActivePane, runCell). End-to-end validation is the
databricks-eng e2e run (requires the harness).
Co-authored-by: Isaac
rugpanov
force-pushed
the
fix/run-dbconnect-progress-bar-stall
branch
from
510d98b to
03a6b8a
Compare
Contributor
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
Contributor
Author
|
🤖 Integration tests ❌ 6 of 35 test jobs failed for |
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
1 participant
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
Fixes the flaky
run_dbconnect.ucwsnotebook + magic tests.Run All/Jupyter: Run All Cellsruns the first DBConnect cell but doesn't advance tothe rest in the headless CI harness, so later cells stay
<not run>and theexpected
*-output.jsonfiles are never written.Evidence this is harness-only, not a product bug
success=true, later cells<not run>.Run Allranboth
.ipynbcells; running the.pyDatabricks-notebook cells one-by-onethrough the kernel produced all four output files (
hello world,hello; world,hello run;). The progress-bar ipywidget was present throughout and did notblock advancement.
So the auto-advance stall is specific to webdriver/xvfb, not real users. The fix
stays in the test and keeps execution going through VS Code (real kernel + the
extension's injected
spark/%sql/_sqldf/%runmagics).What changed
executeNotebookCell(i)/runRemainingActiveNotebookCells()helpers thatrun cells via the VS Code
notebook.cell.executecommand.Run All. (An earlier approach drove cells from the start and hung with"Remote command timeout exceeded" — executing a cell with no kernel opens a
modal kernel picker that never resolves the
executeWorkbenchpromise.)Run All→ wait for cell 0 output → run cell 1 (%run) explicitly.Run All Cells→ wait until first cell has an executionOrder → runremaining cells → assert both
%sql→_sqldfand%runoutputs.Verification
tsc/eslint/prettier clean; esbuild+keepNames shows 0__namein the callbacks.produced all outputs).
This pull request and its description were written by Isaac.