mirror of
https://github.com/openai/codex.git
synced 2026-11-07 08:34:29 +00:00
riley-oai
82d4a98912
## Why
Canceling an elicitation does not stop a separate native verification RPC. Clients need a way to cancel that work and prevent a canceled proof from being delivered while it waits for outbound queue capacity.
## What changed
- Add experimental `userVerification/cancel` with `{requestId}` to signal cancellation of status, enroll, delete, or verify requests on the same connection.
- Return an empty acknowledgment without waiting for native work to exit. Unknown, finished, unrelated, and other-connection requests are no-ops.
- Retain request cancellation state until outbound capacity is available so canceled proofs are checked before enqueueing. Already enqueued responses and completed effects cannot be retracted.
- Document the API, request ID requirements, and independent lifetimes of elicitations and native verification RPCs.
## Testing
Add coverage for experimental opt-in, parameter validation, connection and request ID isolation, cancellation before native dispatch, repeated cancellation, worker-slot retention, and proof cancellation while waiting for outbound capacity.
GitOrigin-RevId: 03fcb83fcc5fab4169c68668822fc0bbb4970938
34 lines
1.8 KiB
Markdown
34 lines
1.8 KiB
Markdown
# User verification cancellation (experimental)
|
|
|
|
Local UI clients can cancel a native user-verification RPC by sending
|
|
`userVerification/cancel` with `{requestId}` and the `experimentalApi` opt-in.
|
|
The result is an empty acknowledgment (`{}`). This API does not enable desktop
|
|
verification capability advertisement.
|
|
|
|
`requestId` is the original status, enroll, delete, or verify RPC's string or
|
|
integer ID on the same connection, not the server elicitation ID. Use fresh IDs
|
|
for each operation and a distinct ID for the cancel RPC. Unknown, finished,
|
|
unrelated, and other-connection requests are no-ops.
|
|
|
|
The acknowledgment confirms the cancellation signal without waiting for the OS
|
|
prompt to close. The original RPC completes independently, with
|
|
`cancelled/interrupted` when cancellation prevents completion. Cancellation
|
|
cannot roll back completed effects. It remains effective while a proof waits for
|
|
outbound queue capacity, but cannot retract a response already enqueued.
|
|
|
|
Canceling or resolving an elicitation does not itself stop a separate
|
|
`userVerification/verify` RPC. Clients must cancel that RPC separately and discard
|
|
late proofs after the approval is canceled or resolved. Only one native worker
|
|
runs per app-server; if an OS call remains active after cancellation or timeout,
|
|
subsequent local operations return `failed/providerError` until that worker exits.
|
|
|
|
# Thread removal
|
|
|
|
`thread/archive` and `thread/delete` reject attempts to remove a live internal
|
|
worker with JSON-RPC error `-32600`. The worker's owner controls its shutdown.
|
|
For example, a Guardian reviewer remains available to its parent conversation
|
|
after a client tries to archive or delete it.
|
|
|
|
After the owner releases the worker, its saved conversation can be archived or
|
|
deleted normally. Ordinary client-controlled threads keep their existing behavior.
|