-
Notifications
You must be signed in to change notification settings - Fork 134
feat(workspace): identity in the prompt, and a /workspace menu for refresh, sync and unlink #1278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
b87577d
e0e8ed2
ae80f16
02be1fd
d3382e0
116a03c
e3f3237
23b4760
586cc54
5571fe3
3d1cab7
66273f7
a45b2ed
1701078
3c563e1
976a874
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -352,6 +352,34 @@ export namespace WorkspaceApi { | |
| return null | ||
| } | ||
|
|
||
| /** Detach this project from its workspace, server-side. | ||
| * | ||
| * Returns false when the server had no active binding to remove — the project | ||
| * was already unlinked, by someone else or on another machine. That is a | ||
| * distinct outcome from "removed", not an error, so the caller can tell the | ||
| * user which happened. | ||
| * | ||
| * A local-only unlink is not possible: ``lookupBinding`` re-asks the server | ||
| * whenever the cache misses, so a row dropped only on disk comes straight back | ||
| * on the next resolve. */ | ||
| export async function unbindProject(id: ProjectIdentifier): Promise<boolean> { | ||
| const query: Record<string, string> = {} | ||
| // Send exactly one identifier. The endpoint answers 409 when both are given | ||
| // and they name different bindings, and preferring the remote matches how | ||
| // ``getBindingForProject`` resolves — so unlink removes the binding that | ||
| // lookup would have found. | ||
| if (id.repoRemote) query.repo_remote = id.repoRemote | ||
| else if (id.projectPath) query.project_path = id.projectPath | ||
| else return false | ||
| try { | ||
| await req<unknown>("DELETE", "/", { query, allowEmptyBody: true }) | ||
| return true | ||
| } catch (err) { | ||
| if (err instanceof NotFoundError) return false | ||
| throw err | ||
|
Comment on lines
+377
to
+379
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
When Useful? React with 👍 / 👎.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. By design, and the PR text is the part that was wrong, not the code: C3 should read "local cleanup runs on 204 and 404, never on an error". A 404 means the server has no active binding under the identifier unlink resolved — the identifier the row was recorded with, or the arm the server itself said it matched on (116a03c8c2; the pre-check no longer swallows transport errors as of 586cc54987) — which is precisely when a stale local row most needs clearing. The API boundary reports the two outcomes distinctly ( |
||
| } | ||
| } | ||
|
|
||
| export async function createAndBind(input: { | ||
| name: string | ||
| identifier: ProjectIdentifier | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
P1: When DELETE returns 404, this reports success instead of an error.
manage.unlinkthen clears local state, so a stale or non-normalized identifier can leave the server binding intact and silently re-adopt it later; propagate 404 and retain local state.Prompt for AI agents
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By design, and documented on
unbindProjectandManage.unlink: a 404 means the server has no active binding under that identifier, which is exactly when a stale local row most needs clearing. The risk you describe — a wrong identifier producing a 404 that clears a live binding — is closed on the other side: unlink deletes on the identifier the row was recorded with, and when there is no row it asks the server which arm it matched on first (116a03c8c2). As of 586cc54987 that pre-check no longer swallows transport errors either, so the only way to reach the 404 branch is with the identifier the server itself resolved. The TUI reports the two outcomes differently ("Unlinked from X" vs "already unlinked").