Skip to content

WorkspaceTrustManagementService.setUrisTrust() resolves before asynchronous Workspace Trust transition completes #328625

Closed

Description

Does this issue occur when all extensions are disabled?: Yes

  • VS Code Version: Current main branch (built from source)
  • OS Version: Windows 11 24H2 (Build 26200.x)

Summary

WorkspaceTrustManagementService.setUrisTrust() invokes the asynchronous doSetUrisTrust(...) operation without awaiting its completion.

As a result, callers awaiting setUrisTrust() (and transitively setWorkspaceTrust()) can resume execution before the Workspace Trust transition has fully completed. At the time the returned promise resolves, asynchronous Workspace Trust transition participants may still be running and the onDidChangeTrust event may not yet have been emitted.

This results in inconsistent completion semantics for the public asynchronous API, since awaiting the method does not guarantee that the entire Workspace Trust transition has finished.


Root Cause

The current implementation starts the asynchronous transition by calling:

this.doSetUrisTrust(...);

without awaiting or returning the resulting promise.

Although the trust update process continues asynchronously, the public Promise<void> returned by setUrisTrust() resolves immediately after the asynchronous operation has been started rather than after it has completed.

Because setWorkspaceTrust() awaits setUrisTrust(), its completion semantics are also affected.


Steps to Reproduce

  1. Register a controlled asynchronous Workspace Trust transition participant.
  2. Call and await:
await workspaceTrustManagementService.setWorkspaceTrust(true);
  1. Prevent the transition participant from completing immediately.
  2. Observe the state immediately after the awaited call returns.

The following state is observed:

participantStarted: true
participantCompleted: false
trustChangeEventFired: false
setWorkspaceTrustResolved: true
trusted: true

The returned promise resolves even though:

  • the transition participant has not completed; and
  • the Workspace Trust change notification has not yet been emitted.

Expected Behavior

setWorkspaceTrust() should not resolve until the complete Workspace Trust transition has finished, including:

  • persistence of trust state;
  • Workspace Trust recomputation;
  • execution of asynchronous transition participants; and
  • emission of the onDidChangeTrust event.

Awaiting the public API should represent completion of the full trust transition.


Actual Behavior

setWorkspaceTrust() resolves immediately after doSetUrisTrust(...) has been started.

The asynchronous transition continues after the public promise has already resolved, allowing callers to resume before transition participants and trust-change notifications have completed.


Proposed Fix

Await the asynchronous doSetUrisTrust(...) call inside setUrisTrust().

async setUrisTrust(uris: URI[], trusted: boolean): Promise<void> {
    await this.doSetUrisTrust(
        await Promise.all(uris.map(uri => this.getCanonicalUri(uri))),
        trusted
    );
}

This preserves the intended asynchronous semantics by ensuring that the returned promise resolves only after the complete Workspace Trust transition has finished.


Validation

To verify the behavior, I added a regression test that:

  • registers a controlled asynchronous Workspace Trust transition participant;
  • awaits setWorkspaceTrust(true);
  • verifies that the returned promise does not resolve until:
    • transition participants have completed; and
    • onDidChangeTrust has been emitted.

Before the change, the regression test fails because the promise resolves prematurely.

After awaiting doSetUrisTrust(...):

  • the regression test passes;
  • the Workspace Trust test suite passes; and
  • no additional regressions were observed.

Additional Notes

While reviewing the Workspace Trust implementation, I identified this asynchronous ordering issue and prepared a minimal fix together with a regression test demonstrating the current behavior and validating the proposed change.

I have also created a pull request implementing this fix and the accompanying regression test.

Activity

  1. mayannkkk19 commented on Aug 2, 2026

    @mayannkkk19

    Hello Maintainers, i would love to work upon this issue.
    Can I get an assignment?

  2. zainnadeem786 commented on Aug 2, 2026

    @zainnadeem786
    ContributorAuthor

    Hi mayannkkk19, thanks for your interest. I’m already working on this issue and preparing a pull request with a fix and regression test.

  3. mayannkkk19 commented on Aug 2, 2026

    @mayannkkk19

    Sure thing Zain Nadeem (@zainnadeem786) , thanks for the confirmation!

  4. added this to the 1.135.0 milestone on Aug 19, 2026
  5. added
    unreleasedPatch has not yet been released in VS Code Insiders
    insiders-releasedPatch has been released in VS Code Insiders
    and removed
    unreleasedPatch has not yet been released in VS Code Insiders
    on Aug 19, 2026
  6. locked and limited conversation to collaborators on Oct 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

bugIssue identified by VS Code Team member as probable buginsiders-releasedPatch has been released in VS Code InsidersverifiedVerification succeededworkspace-trustTrusted workspaces

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions