fix(lsp): surface module-level uncaught errors in test runs#34641
Merged
Conversation
When a test module throws while evaluating — for example `Deno.test("")`
which throws "The test name can't be empty" — the `UncaughtError` event is
emitted before any test registers at runtime. `LspTestReporter::report_uncaught_error`
only reported failures for tests already registered dynamically, so the error
was silently dropped: the test run ended with no indication of what went wrong
(historically this also panicked/hung the language server, see #17119).
Fall back to reporting the failure against the module's statically-collected
tests (already enqueued on the client) when no dynamic test matches the origin,
and against the module itself as a last resort, so the run always surfaces the
error instead of completing silently.
Co-Authored-By: Divy Srivastava <[email protected]>
The `wpt release linux-x86_64` check failed as a flake (the same job also failed on the base commit 81b0b58 on main while neighbouring commits passed). This change set is LSP-only and cannot affect Web Platform Tests; the release deno binary builds fine (all other release jobs are green). Pushing to give the flaky job a fresh run. Co-Authored-By: Divy Srivastava <[email protected]>
`build debug linux-aarch64` was canceled by an infra/runner issue ("The
operation was canceled") while the same source built successfully on all other
targets (including build release linux-aarch64 and build debug macos-aarch64).
The `lint title` and `wpt` checks are now green, so re-running should turn CI
fully green.
Co-Authored-By: Divy Srivastava <[email protected]>
The node_compat shard (1/3) passed on linux-x86_64, linux-aarch64 and windows-x86_64 release, and shards 2/3 and 3/3 passed on windows debug, so the single debug/windows-x86_64 failure is a known flake. This change set is LSP-only and cannot affect Node compatibility. All other checks (including the previously-flaky wpt and build debug linux-aarch64) are green; re-running to clear the flake. Co-Authored-By: Divy Srivastava <[email protected]>
`deno_core test linux-x86_64` failed with `System.IO.IOException: No space left on device` on the GitHub runner — a pure infra failure unrelated to this LSP-only change (which does not touch deno_core). A fresh runner should have disk space; re-running to clear it. Co-Authored-By: Divy Srivastava <[email protected]>
6 tasks
littledivy
added a commit
to crowlKats/deno
that referenced
this pull request
Jun 10, 2026
…#34641) Closes denoland/divybot#368 --------- Co-authored-by: divybot <[email protected]> Co-authored-by: Divy Srivastava <[email protected]>
littledivy
added a commit
that referenced
this pull request
Jun 24, 2026
…34905) ## Summary When a user's `deno.json` declares a `test` task with `--env-file=…`, the LSP test runner (used by the VSCode test gutter) silently ignored it. Tests that read env vars at module load — `Deno.env.get("MY_SECRET")` — threw before any test ran, and VSCode surfaced this as the confusing "The test run did not record any output". The "no-output" silent-drop symptom was fixed in #34641 (#17119). This PR addresses the remaining maintainer-raised question from that thread: should the LSP runner honor the `test` task's flags? It picks up `--env-file`/`--env` from the `test` task and merges them into the LSP test run. Mechanics: - `TestRun::init` now walks each unique scope reached by the queued specifiers and parses the scope's deno.json `test` task command with shlex, harvesting `--env-file=…` / `--env=…` / bare `--env-file` (→ `.env`) flags from `deno test ...` command segments. Each path is resolved against the deno.json's directory so the LSP process's CWD doesn't change the answer. - `get_args` appends those env-file flags to the LSP test run unless the user already supplied an env-file flag via `deno.testing.args` (so existing setups keep their explicit value). Inherited paths are kept as `PathBuf` until CLI arg emission; non-UTF8 paths are skipped with an LSP log entry rather than lossy-converted. - The LSP test execution path calls `WatchEnvTracker::snapshot().load_env_variables_from_env_files(...)` before constructing the worker factory, mirroring the CLI test behavior while allowing subsequent LSP runs to refresh changed/removed env-file variables. The remaining shared-process limitation is documented and covered by a regression test: two scopes setting the same key cannot both observe their own value in one LSP process. ## Test plan - [x] `cargo test -p deno --lib lsp::testing::execution::tests::test_extract_env_files_from_command --features rustls/ring -- --nocapture` — unit test covering `=`-form, bare flag (→ `.env`), `--env` alias, multiple, compound shell tasks, quoted paths with whitespace, unrelated non-test env flags, and malformed input. - [x] `cargo test -p integration_tests --test integration lsp_testing_api_inherits_test_task_env_file -- --nocapture` — LSP integration test: deno.json with `tasks.test: deno test --env-file=.env.test -A`, test.ts reads `MY_SECRET` at module load, asserts the test passes (would throw at module eval without the env file). - [x] `cargo test -p integration_tests --test integration lsp_testing_api_test_task_env_file_conflicting_scopes_first_wins -- --nocapture` — documents the current same-key shared-process env limitation across scopes. - [x] `cargo build -p deno -p test_server`. - [x] `cargo clippy -p deno --bin deno --no-deps` clean. - [x] `cargo fmt --check` clean. Refs #28797 Closes denoland/divybot#487 --------- Co-authored-by: divybot <[email protected]> Co-authored-by: Divy Srivastava <[email protected]>
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.
Closes denoland/divybot#368
Fixes #17119