[app-server] Add cancellation registry and $/cancelRequest

[celia-oai]

Add cancellation registry and $/cancelRequest, so that long-running Json-RPC endpoints can orchestrate their own cancellation logic. This is in line with the LSP protocol (doc). Registered cancellation for login_chatgpt, so $/cancelRequest performs the same as the legacy cancelLoginGpt endpoint.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Allow FnOnce cancellation callbacks

The new registry only accepts F: Fn() + Send + 'static, which means every cancellation action must implement Fn. That rules out the most common patterns for cancelling background work, e.g. signalling a tokio::sync::oneshot::Sender or taking ownership of an abort handle, because closures such as move || tx.send(()) are only FnOnce. Trying to register one of those today will not compile, so long-running requests that rely on a one-shot cancel signal still cannot integrate with $/cancelRequest, defeating the purpose of this feature. Please change the registry to handle FnOnce callbacks (e.g. by storing them behind an Option/Mutex so they can be invoked exactly once).

Useful? React with 👍 / 👎.

[owenlin0]

ah very interesting that this is done as a notification. makes sense after reading https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#cancelRequest

[owenlin0]

ah, looks like this might not be applicable to login. the use case for a $/cancelRequest call seems to be:

1. client makes a request to server
2. server is processing, no response sent yet
3. client sends a $/cancelRequest notification
4. server responds to the original request with a response with ErrorCodes.RequestCancelled

so this seems generally useful to interrupt long-running operations.

whereas with chatgpt login, we do:

1. client makes an account/login request
2. server immediately responds with {"login_id": uuid, "auth_url": }, where the url needs to be opened in a webview on the client
3. user authenticates via the webview
4. server sends a notification to the client indicating the login was successful

the auth URL looks like:
https://auth.openai.com/oauth/authorize?response_type=code&client_id=app_EMoamEEZ73f0CkXaXp7hrann&redirect_uri=http%3A%2F%2Flocalhost%3A1455%2Fauth%2Fcallback&scope=openid%20profile%20email%20offline_access&code_challenge=[code]&code_challenge_method=S256&id_token_add_organizations=true&codex_cli_simplified_flow=true&state=[state]&originator=codex_cli_rs

So the codex process starts up an HTTP server on port 1455 to listen for the redirect after login is successful, and then update its auth storage. Asking codex, looks like it'll time out in 10 mins if user doesn't complete login flow and there's no cancellation. We expose the CancelChatGptLogin request as a way to immedately cancel the login, mostly for UX I think (i.e. they can render a "cancel login" button in their UI).

tldr my 2c: based on our convo with pavel, I think we actually want to name it account/login/start and pair it with account/login/cancel since the login request returns immediately with a URL

[owenlin0]

sorry for the back and forth on this!

[celia-oai]

closed in favor of accounts/login/cancel