From 7df9763aa52435efa31afbe2308a418ef9f91151 Mon Sep 17 00:00:00 2001
From: Danny Canter <danny_canter@apple.com>
Date: Mon, 22 Sep 2025 14:17:38 -0700
Subject: [PATCH] ClientContainer: Remove response timeout from `stop` (#667)

After the large reworks, I'm not as worried about having this timeout
anymore. Prior to the reworks stop was signaled via an async event sent
to the daemon as stop was performed directly on the given runtime-helper
instance. If anything errored during that it was common for things to
explode, but now that stop is:

client -> APIServer -> runtime-helper instance

and the logic for stop has been improved quite a bit, in addition to
stop no longer holding a lock during it's operation, I'm not sure we
need this. In the future it'd also be nice to support no timeout (the
timeout until we send SIGKILL, not response timeout) in which case we'd
have to have an extra bit of logic here to skip the response timeout in
that scenario anyways.
---
 Package.resolved                                   | 2 +-
 Sources/ContainerClient/Core/ClientContainer.swift | 8 +-------
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/Package.resolved b/Package.resolved
index 414623d6..a8243949 100644
--- a/Package.resolved
+++ b/Package.resolved
@@ -1,5 +1,5 @@
 {
-  "originHash" : "23302f085b6239754a405a0a6ec0dcaad1d48086319c3eaa5a5650b4bf2670e5",
+  "originHash" : "a04bb1d08ef1fca925fcfe3250303675ad17c962fecc35b23972ebb8598bb63f",
   "pins" : [
     {
       "identity" : "async-http-client",
diff --git a/Sources/ContainerClient/Core/ClientContainer.swift b/Sources/ContainerClient/Core/ClientContainer.swift
index a110fe50..b8b0999b 100644
--- a/Sources/ContainerClient/Core/ClientContainer.swift
+++ b/Sources/ContainerClient/Core/ClientContainer.swift
@@ -196,13 +196,7 @@ extension ClientContainer {
             request.set(key: .id, value: self.id)
             request.set(key: .stopOptions, value: data)
 
-            // Stop is somewhat more prone to hanging than other commands given it
-            // has quite a bit of `wait()`'s down the chain to make sure the container actually
-            // exited. To combat a potential hang, lets timeout if we don't return in a small
-            // time period after the actual stop timeout sent via .stopOptions (the time
-            // until we send SIGKILL after SIGTERM if the container still hasn't exited).
-            let responseTimeout = Duration(.seconds(Int64(opts.timeoutInSeconds + 3)))
-            try await client.send(request, responseTimeout: responseTimeout)
+            try await client.send(request)
         } catch {
             throw ContainerizationError(
                 .internalError,