Fix flaky open-connect-content e2e test by zackverham · Pull Request #3677 · posit-dev/publisher

zackverham · 2026-03-09T21:18:41Z

Summary

Fixes the flaky open-connect-content e2e test that was failing across multiple Connect versions (preview, release, 2023.03.0, 2025.03.0).

Root cause

The ConnectContentFileSystemProvider was blocking VS Code's workspace validation during the workspace switch. When updateWorkspaceFolders is called, code-server validates the new folder by calling stat() and readDirectory() on the root URI. Our implementation awaited the full bundle fetch pipeline (Go backend startup → credential refresh → Connect API call → tar extraction) before responding. This caused code-server to silently reject the workspace change because the validation timed out.

Additionally, in code-server, updateWorkspaceFolders creates a multi-root workspace where the content folder appears at aria-level="2" instead of aria-level="1", so the test's CSS selector was missing the GUID entirely.

Extension fixes (`connect_content_fs.ts`)

Non-blocking stat() for root URIs: Returns an immediate directory entry without waiting for the bundle fetch. The bundle is kicked off in the background.
Non-blocking readDirectory() for root URIs: Returns whatever is cached (or [] if nothing yet), then fires a FileChangeType.Changed event when the bundle fetch completes to trigger VS Code to refresh the explorer tree.
Non-blocking error handling: showErrorMessage and the credential dialog are fire-and-forget (void) instead of awaited, so they don't stall the filesystem provider.

Test fixes (`open-connect-content.cy.js`)

Removed aria-level='1' restriction from the GUID selector — matches the folder at any tree depth to handle both single-folder and multi-root workspace modes.
Added notification toast dismissal during polling.
Increased waitUntil timeout to 120s.
Added explorer DOM diagnostics to the error message for easier debugging of future failures.

Test plan

All 4 e2e matrix variants pass (preview, release, 2023.03.0, 2025.03.0)
Unit tests pass (18/18) including new error-handling coverage
Lint and formatting clean

🤖 Generated with Claude Code

Replace URL change detection with direct explorer polling to handle both workspace switch code paths (updateWorkspaceFolders and openFolder). Consolidate 5 retryWithBackoff blocks into a single waitUntil loop with try-catch for page reload safety. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

The connect-content filesystem provider's stat() call was blocked by awaited UI dialogs (showErrorMessage, credential flow), preventing the explorer from rendering the workspace folder during e2e tests. - Move cache population before error notification in fetchAndCacheBundle - Fire-and-forget showErrorMessage and credential dialog instead of awaiting - Increase e2e waitUntil timeout to 120s and dismiss notification toasts - Add unit tests verifying stat/readDirectory resolve on fetch failure Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Screenshots show the workspace switch never happens on preview and 2023.03.0 - the URL stays at /?folder=/home/coder/workspace. Adding cy.log diagnostics to capture: content record values, URL after command, explorer state, notification messages, and quick input visibility during the waitUntil polling loop. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

The workspace switch via updateWorkspaceFolders was silently failing because code-server validates new workspace folders by calling stat() on the root URI. The stat() call blocked on the bundle fetch (which depends on Go backend readiness and Connect API), causing code-server to reject the workspace change entirely. Now stat() returns an immediate directory entry for root content URIs (/{guid}) without waiting for the bundle. The bundle fetch is kicked off in the background and the actual content loads lazily when readDirectory() is called by the explorer. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

On Connect 2023.03.0, code-server was dropping the connect-content workspace folder because readDirectory() blocked on the bundle fetch. When the bundle takes too long (slow Connect API, Go backend startup), code-server rejects the workspace change. Now readDirectory() returns an empty list immediately for root URIs if the bundle hasn't been cached yet, and fires a FileChangeType.Changed event when the fetch completes to trigger VS Code to refresh the tree. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

In multi-root workspace mode (triggered by updateWorkspaceFolders in code-server), the workspace name appears at aria-level 1 and the connect-content folder drops to aria-level 2. The previous selector only checked level 1, missing the GUID folder entirely. Now the test searches for the GUID anywhere in the explorer tree regardless of nesting level. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Include the actual explorer row contents (text + aria-level) in the failure error message so we can see exactly what the DOM contains when the GUID selector doesn't match. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

christierney · 2026-03-11T16:07:49Z

+    // The actual bundle is fetched lazily when readDirectory() is called.
+    if (isRootContentUri(uri)) {
+      // Kick off the bundle fetch in the background so readDirectory() is faster
+      void this.ensureBundleForUri(uri);


what does void do here?

claude is indicating that this is to avoid linting errors because this is an asynchronous promise that we are explicitly not awaiting on.

https://typescript-eslint.io/rules/no-floating-promises/

Interesting we don't use plugin:@typescript-eslint/recommended-type-checked but probably still a valid call.

It discards the return value of this.ensureBundleForUri so doesn't use the Promise at all.

dotNomad

Caught a bug with this. Detailed in an inline comment.

dotNomad · 2026-03-11T17:59:53Z

+    // The actual bundle is fetched lazily when readDirectory() is called.
+    if (isRootContentUri(uri)) {
+      // Kick off the bundle fetch in the background so readDirectory() is faster
+      void this.ensureBundleForUri(uri);


Interesting we don't use plugin:@typescript-eslint/recommended-type-checked but probably still a valid call.

dotNomad · 2026-03-11T18:42:10Z

+    // The actual bundle is fetched lazily when readDirectory() is called.
+    if (isRootContentUri(uri)) {
+      // Kick off the bundle fetch in the background so readDirectory() is faster
+      void this.ensureBundleForUri(uri);


It discards the return value of this.ensureBundleForUri so doesn't use the Promise at all.

dotNomad · 2026-03-11T18:44:16Z

+    // immediately so that updateWorkspaceFolders / openFolder can validate the
+    // workspace folder without waiting for the (potentially slow) bundle fetch.
+    // The actual bundle is fetched lazily when readDirectory() is called.
+    if (isRootContentUri(uri)) {


I didn't understand why we only returned right away if we were looking at a root content Uri. I did a bit of digging and VS Code stats the root URI during workspace folder validation. Since other sub-paths are accessed after the explorer is rendered we only need the special handling here.

dotNomad · 2026-03-11T18:52:32Z

+    // Launch the credential dialog without awaiting it. Blocking here would
+    // stall the filesystem provider's stat() call, preventing the explorer
+    // from rendering anything until the user completes the dialog.
+    void commands.executeCommand(
      Commands.HomeView.AddCredential,
      normalizedServer,
    );
-    await state.refreshCredentials();
-    if (hasCredentialForServer(normalizedServer, state)) {
-      return normalizedServer;
-    }


I don't think this is right. This means we would throw an error immediately while trying to add a credential doesn't it?

You can see the bad behavior if you try to open connect content on a server that you don't have credentials for yet.

It leaves you in a bad state where you have an error for no valid credentials, and an empty temporary workspace, which isn't great.

I changed this to

logger.warn( `No credentials for ${normalizedServer}. Opening credential flow.`, ); // Await the credential dialog so the user can authenticate on the first // try. This runs inside the background bundle fetch, so it won't block // stat() or readDirectory() — those return immediately for root URIs. await commands.executeCommand( Commands.HomeView.AddCredential, normalizedServer, ); await state.refreshCredentials(); if (hasCredentialForServer(normalizedServer, state)) { return normalizedServer; } throw new Error(`No valid credentials available for ${normalizedServer}`);

and that worked much better. I didn't get the "no valid credentials" error, but it take a bit of time for the files to load in. I don't think that is a blocker, but something that could be improved in the future. I thought it wasn't working for a second.

zackverham · 2026-05-05T14:20:13Z

@christierney @dotNomad I haven't been noticing this test flaking out as much as it used to - I'm considering closing this as a red herring.

zackverham and others added 8 commits March 9, 2026 17:18

Fix Prettier formatting

83e7e63

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

christierney reviewed Mar 11, 2026

View reviewed changes

dotNomad requested changes Mar 11, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix flaky open-connect-content e2e test#3677

Fix flaky open-connect-content e2e test#3677
zackverham wants to merge 8 commits into
mainfrom
fix-open-connect-content-flaky-test

zackverham commented Mar 9, 2026 •

edited

Loading

Uh oh!

christierney Mar 11, 2026

Uh oh!

zackverham Mar 11, 2026

Uh oh!

dotNomad Mar 11, 2026

Uh oh!

dotNomad Mar 11, 2026

Uh oh!

dotNomad left a comment

Uh oh!

dotNomad Mar 11, 2026

Uh oh!

dotNomad Mar 11, 2026

Uh oh!

dotNomad Mar 11, 2026

Uh oh!

dotNomad Mar 11, 2026

Uh oh!

dotNomad Mar 11, 2026

Uh oh!

zackverham commented May 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

zackverham commented Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Root cause

Extension fixes (connect_content_fs.ts)

Test fixes (open-connect-content.cy.js)

Test plan

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dotNomad left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zackverham commented May 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

zackverham commented Mar 9, 2026 •

edited

Loading

Extension fixes (`connect_content_fs.ts`)

Test fixes (`open-connect-content.cy.js`)