fix: Fix inconsistent workspace handling in agent #7160
+118
−51
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.
While trying to adapt #6947 to the changes from #6909, I noticed that workspace handling is inconsistent in the agent.
In particular:
workspaceRootUri
upon initialization and stores it onAgentWorkspaceDocuments
. This valueeventually ends up in
workspaceFolders
.workspaceFolder/didChange
, which updatesworkspaceFolders
but doesn't affectworkspaceRootUri
inany way.
getWorkspaceFolder
andasRelativePath
ignoreworkspaces
and work directly withworkspaceRootUri
So it seems that any client that wants to use
workspaceFolder/didChange
will eventually end up with an inconsistent state.This PR aims to fix that. It removes
workspaceRootUri
and updates all places that used it to work withworkspaceFolders
instead.asAbsolutePath
was updated to use the extension URI instead, which seems more in line with what the purpose of that method is (though it doesn't seem like we use it anywhere).workspaceFolders
is still initialized from the client info, directly instead of going throughworkspaceDocuments
.Test plan
I've tested this manually in the context of #6947 and https://github.com/sourcegraph/sourcegraph/pull/3333. The following secanarios work as expected:
Current repository
at-mentions entry point to the current repository, as well the default file filtering logic only suggest files from the current repository)file search correctly resolve to the new repository.
Note
What I've not been able to successfully test is the
Rules
provider. But I suspect that there might be unrelated issueswith it, because the network requests it made in the web demo resulted in 428 errors, saying that the
X-Requested-Width
header was missing.