A stop request must survive startup and reach cleanup

Original research record

A stop request must survive startup and reach cleanup

We connect new VS Code and vLLM changes around stopping AI work. VS Code gives selected background shells a Stop action. vLLM preserves a stop request received before its engine exists, and separately changes how communication resources are collected. We infer that a stop needs three checks: it reaches the intended work, it survives startup, and the resources are actually released.

We see different gaps between asking work to stop and knowing it has ended. A new VS Code Agent Host change offers Stop only for background work marked as stoppable. Its Copilot path marks attached shells, sends their ID to the runtime cancellation request and returns the runtime’s result. Detached shells are outside this new control. [VS Code change](https://github.com/microsoft/vscode/commit/6eb5f37d1c05683262724dba334221290d8f4188)

In vLLM, a termination request can arrive while the engine is still being built. The new code records that request in a separate flag because the engine object does not yet exist. Once construction finishes, it applies the request before starting normal work. It also keeps a one-use wakeup callback available for a later signal. This preserves a request; it does not promise to interrupt every startup operation immediately. [Startup change](https://github.com/vllm-project/vllm/commit/c4a5ff5c18ceba5f06512ef6b17a48338f275763)

A separate vLLM change closes messaging sockets before their shared context during object collection. That targets a case where linked objects can keep cleanup waiting. Its new test puts a reader in a reference cycle and checks that collection returns. We connect the three records as a lifecycle test: correct target, remembered request, verified cleanup. They are separate code paths, with no claimed VS Code-to-vLLM dependency. [Cleanup change](https://github.com/vllm-project/vllm/commit/9bbc58156095f45bdb91ddbdbd244119d3afb12c)

Key points We checked that VS Code’s new request names a chat and work ID. Only explicitly marked work gets the control. The Copilot test expects cancellation for an attached shell, but not a detached or unknown one. We read vLLM’s startup test definitions. They check that an early stop request is present before the busy loop and that a later signal can still wake an idle loop. They use stand-ins, not a running GPU model. We checked the messaging cleanup order: sockets close before the context ends. The finalizer is set not to run automatically at interpreter exit. This is a targeted object-collection fix, not proof of every exit path. We would test stopping before startup finishes, during active work and after apparent completion. Record the request result separately from process exit and released resources.

What could change this view? We have not reproduced a failure or measured shutdown time. VS Code’s runtime can already report whether cancellation occurred; the new UI does not establish a missing cancellation feature in every older client. vLLM applies the saved request after construction and does not guarantee an immediate stop during a blocked startup step. Its collection test and socket-order fix cover one failure path. These changes cannot prove that every child process ends or that all memory is reclaimed. Existing deployment supervision may already handle some failures.

Bottom line We would judge Stop by the resulting state of the work and its resources. A visible button and a returned cancellation result are useful, but a reliable shutdown test also checks early requests and cleanup. No investment direction or measured cost saving applies.

How likely is this call? · Three frameworks This signal has no investible bullish or bearish call. A market-direction percentage does not apply. Bayesian · what changed the estimate? New source records identify specific stop-routing, startup and cleanup paths. We have no fitted failure prior or likelihood, so we make no numerical update. de Finetti · are the comparisons fair? A chat-shell request, an engine-startup test and a messaging-object collection test are different situations. Two commits also share vLLM as their source. We do not pool them as independent deployment trials. Kolmogorov · do the numbers agree? We assign no bullish, bearish or neutral percentages. An accepted stop request and completed resource cleanup are separate states; neither can be counted as proof of the other. Market neutral band, horizon, deadline and price basis: Not applicable. Research gaps: independent lifecycle tests, containing releases and real process/resource observations. Read the shared method: https://new.ontherice.org/how-otr-works/#probability-framework.

Evidence behind this view We connect OTR Database Data Technology attempts 93 and 94, then reopen exact first-party changes. VS Code’s attached-shell Stop change was committed at 17:19:56 UTC on 8 October. vLLM’s early termination-request change followed at 18:46:01 UTC and its messaging cleanup change at 18:53:00 UTC. These are two project-origin clusters and three distinct mechanisms, all after the prior edition’s 17:17 UTC cutoff. The code and tests support the scoped claims; no interoperability or end-to-end run was tested.

What past price moves show Not applicable to market prices. An earlier OTR Social card asked whether closing a window really stopped remote work and connected requests for verifiable cancellation with reports of leftover processes. We preserve that general control question. This view adds later, directly inspected implementation evidence for two narrower mechanisms: remembering termination while an engine is still being constructed, and closing communication resources in the right order during object collection. Earlier serving-stall and restart cards address other stages of work.

Evidence against this view We have not reproduced a failure or measured shutdown time. VS Code’s runtime can already report whether cancellation occurred; the new UI does not establish a missing cancellation feature in every older client. vLLM applies the saved request after construction and does not guarantee an immediate stop during a blocked startup step. Its collection test and socket-order fix cover one failure path. These changes cannot prove that every child process ends or that all memory is reclaimed. Existing deployment supervision may already handle some failures.

Why the direction changed No market direction applies. We add a new operational question built from later source changes: did the stop request survive the period before its target existed, and did cleanup then complete? No previous investment reference, deadline, probability or result changes.

What people say vs the facts We did not collect a representative user or incident sample. The source tests specify intended behavior and contributors describe bounded failure paths. They do not establish widespread runaway agents, rising failure rates, user losses or universal product availability.

How past forecasts performed We have no matched set of resolved operational forecasts or deployment trials. We provide no shutdown-success percentage, incident rate, savings estimate or investment return. Mock tests and source inspection cannot supply those measurements.