Hyperdrive.connect() crashes the whole process with SIGSEGV when the binding's designator points at a Worker service instead of an external service

[mack-erel]

What version of workerd are you using?

1.20260722.1 (also present in 1.20260423.1 and 1.20260317.1 — not bisected further; the code path involved, src/workerd/api/hyperdrive.c++, has not materially changed across these).

Binaries tested (all from @cloudflare/workerd-darwin-arm64 / the workerd npm package, as vendored by workers-sdk's miniflare):

$ ./workerd --version
workerd 2026-07-22

Platform: macOS 26 (Darwin 25.5.0), arm64.

What happened?

workerd's hyperdrive binding (Hyperdrive::connect() in src/workerd/api/hyperdrive.c++) assumes its designator always resolves to an external (raw TCP) service, because that is the only configuration Wrangler/Hyperdrive tooling has ever produced. If the designator instead resolves to a Worker service (e.g. a config typo, or a deliberate experiment binding a Hyperdrive-shaped binding at another Worker), calling .connect() on the binding crashes the entire workerd process with SIGSEGV instead of throwing a JS-catchable error.

This is unsupported/unintended usage, but a runtime should never segfault in response to a misconfiguration reachable from a config file + JS binding call — it should throw (e.g. TypeError) like the analogous "worker doesn't export a connect() handler" case already does correctly (see below).

Discovery context

Found while locally prototyping a Hyperdrive-over-remote-binding relay for local dev (routing a hyperdrive binding's designator at another Worker service instead of external, as a workaround/experiment), as a follow-up to cloudflare/workers-sdk#14710 and #14712. Not encountered via any production Hyperdrive config; no Hyperdrive config id, account id, or credentials are involved in this reproduction — it is 100% local and self-contained.

What did you expect to happen?

Either:

• connect() throws a catchable JS error (e.g. TypeError: Hyperdrive binding designator must be an external service), same as the existing, correctly-handled case where the connect target Worker doesn't export a connect() handler (workerd/api/global-scope.c++:232, Handler does not export a connect() function.); or
• it works, if pointing a Hyperdrive-shaped binding at a Worker service is meant to be a supported extension point.

Either way: no SIGSEGV, and no impact on other requests/isolates sharing the same workerd process.

How can we reproduce it?

This reproduces with plain workerd serve and a hand-written .capnp config — no workers-sdk, wrangler, or miniflare involved, and no real Postgres/MySQL anywhere. The hyperdrive binding's database/user/password/scheme fields are dummy placeholders; they are never actually used before the crash.

Two Workers:

• worker-a: has a hyperdrive binding named HYPERDRIVE, whose designator is "worker-b" (a Worker service, not external). Its fetch() handler calls env.HYPERDRIVE.connect().
• worker-b: an ordinary Worker that is the (incorrect) target of that designator.

config.capnp

using Workerd = import "/workerd/workerd.capnp";

const config :Workerd.Config = (
  services = [
    (name = "worker-a", worker = .workerA),
    (name = "worker-b", worker = .workerB),
  ],

  sockets = [
    ( name = "http", address = "*:8080", http = (), service = "worker-a" ),
  ]
);

const workerA :Workerd.Worker = (
  modules = [
    (name = "worker", esModule = embed "worker-a.js"),
  ],
  compatibilityDate = "2026-07-01",
  compatibilityFlags = ["experimental", "nodejs_compat"],

  bindings = [
    (
      name = "HYPERDRIVE",
      hyperdrive = (
        # This is the crux of the reproduction: the designator names a Worker
        # service ("worker-b"), not an `external` service as Hyperdrive
        # bindings normally use in production.
        designator = "worker-b",
        database = "postgres",
        user = "postgres",
        password = "postgres",
        scheme = "postgresql",
      ),
    ),
  ],
);

const workerB :Workerd.Worker = (
  modules = [
    (name = "worker", esModule = embed "worker-b-withhandler-nopipe.js"),
  ],
  compatibilityDate = "2026-07-01",
  compatibilityFlags = ["experimental", "nodejs_compat"],
);

worker-a.js

export default {
  async fetch(request, env, ctx) {
    try {
      const socket = env.HYPERDRIVE.connect();
      await socket.opened;
      return new Response("connected: " + JSON.stringify({
        readable: !!socket.readable,
        writable: !!socket.writable,
      }));
    } catch (err) {
      return new Response("caught error (expected, this is fine): " + err.stack, {
        status: 500,
      });
    }
  },
};

worker-b-withhandler-nopipe.js (the crashing target — exports a connect() handler)

export default {
  async fetch(request, env, ctx) {
    return new Response("target-worker fetch() called");
  },
  async connect(socket, env, ctx) {
    await socket.opened;
    // Deliberately do nothing else -- no data is ever piped.
  },
};

Run it

workerd serve config.capnp --experimental --verbose
# in another terminal:
curl -v http://localhost:8080/

curl gets back 200 OK with body connected: {"readable":true,"writable":true} — i.e. the Hyperdrive-side JS connect() call appears to succeed and the HTTP response is flushed to the client — but within roughly a second afterward, the whole workerd process dies with SIGSEGV (confirmed reproducible across 3 separate runs, same relative crash-stack shape each time):

*** Received signal #11: Segmentation fault: 11
stack: 1070c3427 1070c3427 1070c3287 1050f444b 1050c7cf7 1050ca227 1070c9ec7 1050ca77b 1070c9d67 1070caa9f 1070c82c7 1070c8cb3 1045b7e97 10712386f 107123b97 107122403 1071221c3 1045a48f3 1809bbdff

A second run (different ASLR slide, same relative offsets between stack entries, confirming the same code path):

*** Received signal #11: Segmentation fault: 11
stack: 10553b427 10553b427 10553b287 10356c44b 10353fcf7 103542227 105541ec7 10354277b 105541d67 105542a9f 1055402c7 105540cb3 102a2fe97 10559b86f 10559bb97 10559a403 10559a1c3 102a1c8f3 1809bbdff

I was not able to symbolicate these addresses in my environment (no task_for_pid/debugger-attach entitlement available, and no crash report was generated by the OS), so I can't point to an exact line with certainty — see "Suspected root cause" below for candidates found by reading the source.

What narrows down the crash location

• The crash does not require any data to flow over the socket. It reproduces identically whether worker-b's connect() handler pipes the stream (socket.readable.pipeTo(socket.writable)) or does nothing but await socket.opened. So the bug is in the connect handshake completing, not in subsequent stream I/O.
• The crash requires worker-b to actually accept the CONNECT (i.e. have a connect() handler that runs to the response.accept() point in ServiceWorkerGlobalScope::connect(), src/workerd/api/global-scope.c++:198). If worker-b has no connect() handler at all, there is no crash — instead you get a clean, catchable JS error, exactly as designed:

  Received a connect event but we lack a handler. Did you remember to export a connect() function?
  workerd/io/io-context.c++:444: info: uncaught exception; exception = workerd/api/global-scope.c++:232: failed: jsg.Error: Handler does not export a connect() function.
  workerd/api/hyperdrive.c++:39: warning: failed to connect to local database; e = ... Handler does not export a connect() function.
  

  This confirms the missing-handler path (JSG_FAIL_REQUIRE(Error, "Handler does not export a connect() function.")) is safe, and the crash is specific to the success path where the CONNECT is actually accepted cross-Worker.
• The HTTP response to the original fetch() request on worker-a is delivered successfully before the crash, meaning the crash happens in background/deferred work — most likely during teardown of the synthetic connect pipe/IoContext(s) involved, not during the initial connect handshake itself.

Suspected root cause (unconfirmed candidates — for triage, not a definitive diagnosis)

I was not able to get a symbolicated backtrace in my environment, so none of these are confirmed; they're what stood out while reading the code paths that Hyperdrive::connect() exercises when its designator is a Worker service, which is a path that (as far as I can tell) has never been exercised in production because Hyperdrive designators are always external.

1. src/workerd/api/hyperdrive.c++:109-115 (Hyperdrive::connectToDb()):

   auto connectReq = kj::newHttpClient(*service)->connect(
       kj::str(getHost(), ":", getPort()), headers, kj::HttpConnectSettings{});
   
   auto status = co_await connectReq.status;
   
   if (status.statusCode >= 200 && status.statusCode < 300) {
     co_return kj::mv(connectReq.connection);
   }

   kj::newHttpClient(*service) returns a kj::Own<kj::HttpClient> temporary that is never bound to a variable — only the result of ->connect(...) (a ConnectRequest, whose .status is then co_awaited and whose .connection is used) is kept. Compare with the only other in-tree caller of this exact overload, src/workerd/io/worker-interface.c++:118:

   return kj::newHttpClient(*workerInterface).attach(kj::mv(workerInterface));

   which explicitly keeps the returned kj::Own<kj::HttpClient> alive (and ties the wrapped WorkerInterface's lifetime to it). hyperdrive.c++ does neither. If the specific kj::HttpClient adapter/coroutine machinery involved in bridging a WorkerInterface's (i.e. a Worker's) connect() back through this adapter is not as fully self-contained as the external-service path (which is far better trodden), this early-destroyed temporary is a natural place to look for a dangling reference.

2. src/workerd/io/io-context.c++, IoContext::getSubrequestChannel / getSubrequestNoChecks (~line 1000-1030): builds a stack-local TraceContext tracing for the "hyperdrive_connect" operation name and only attaches it to the returned WorkerInterface if (tracing.isObserved()). Worth checking whether tracing/span state differs meaningfully, and is handled correctly, when the destination channel resolves to a full Worker (with its own isolate lock, IoContext, and tracer) versus a raw external TCP connection (which has none of that).

3. src/workerd/io/worker-entrypoint.c++:619-699 (WorkerEntrypoint::connect) and src/workerd/api/global-scope.c++:185-233 (ServiceWorkerGlobalScope::connect): both appear to assume the caller is genuine CONNECT ingress — i.e. a real listening tcp-type socket accepting an external connection (see the comment at global-scope.c++:216-218: "We set isDefaultFetchPort to false here ... but this is not relevant on the TCP server side"). In this repro, the same code path is instead reached synthetically, as the target of a Hyperdrive .connect() subrequest issued from another Worker's IoContext via the kj::newHttpClient(WorkerInterface&) adapter — i.e. two independent IoContexts (worker-a's and worker-b's) share a synthetic in-process pipe rather than a real accepted socket. An ordering/lifetime assumption around that cross-IoContext teardown (worker-a's request finishing and releasing the Hyperdrive Socket/subrequest channel while worker-b's connect() handler and its IncomingRequest::drain() are still unwinding, or vice versa) seems like a plausible place for a use-after-free.

Additional notes

• This is very likely not reachable from any real production Hyperdrive configuration today — Hyperdrive designators are always external services provisioned by Cloudflare's control plane. It surfaced only while experimenting with routing a hyperdrive-shaped binding at a Worker service directly.
• Regardless of "is this configuration supported," a config-file-reachable SIGSEGV is a process-wide crash (all in-flight requests/isolates in that workerd process go down with it), so it seems worth hardening Hyperdrive::connect() / the underlying connect() plumbing to fail gracefully (e.g. reject non-external designators explicitly, or otherwise ensure the same safe-JS-error behavior as the "no connect handler" case) regardless of whether the feature of Hyperdrive-over-Worker-designator is ever supported.
• Full repro files (config + both worker scripts + raw crash logs from two separate runs) are available and can be attached/pasted in full if useful; omitted here only for length.

[mack-erel]

Some follow-up analysis after reading the source more closely — I think the crash is a lifetime asymmetry between external and Worker service targets, which suggests the missing .attach is a symptom rather than the whole fix.

In Hyperdrive::connectToDb() (src/workerd/api/hyperdrive.c++:101-133), the service returned by context.getSubrequestChannel(...) is a coroutine-frame local. At co_return kj::mv(connectReq.connection) the frame — and the service Own with it — is destroyed, so the returned stream has to be self-sustaining.

For an external target that holds:

• ExternalTcpService::startRequest returns {this, kj::NullDisposer::instance} (server.c++:2006) — a non-owning pointer to a server-lifetime singleton, so destroying the service Own is a no-op.
• After co_await addr->connect() the pump promise references only the owned io_stream and the pipe connection, not this (server.c++:2029-2050) — fully self-sustaining once connected.

For a Worker target it doesn't:

• WorkerService/EntrypointService::startRequest returns an owning per-request WorkerInterface with its own IoContext (server.c++:3519+).
• WorkerEntrypoint::connect captures [this, ...] and runs on the worker's own IoContext via context.run(...) (worker-entrypoint.c++:619); the connect-handler promise keeps referencing it, and the socket can outlive the handler via ctx.waitUntil() (global-scope.c++:185-232, see the neuter/deferredNeuter comment at 200-202).

So at co_return the owning WorkerInterface + its IoContext are torn down while the cross-IoContext pipe is still pumping — which lines up with the observed "crash happens in deferred/background work, after the initial handshake" symptom.

That's why copying asHttpClient's .attach(kj::mv(workerInterface)) pattern (worker-interface.c++:118) onto hyperdrive.c++:109 isn't sufficient on its own: the service Own still dies at co_return, and the adapter's connect-pump promise still references the WorkerInterface. A correct fix would need to attach both the adapter and the WorkerInterface Own to the returned stream so they live as long as the socket, and even then the neuter / waitUntil × cross-IoContext teardown ordering would need care.

Given that, the two useful outcomes here seem separable:

1. Defensive hardening (small, self-contained): reject a non-external Hyperdrive designator with a catchable error at bind/connect time, exactly like the existing "worker doesn't export a connect() handler" path (global-scope.c++:232) — no SIGSEGV regardless of whether the feature is ever supported. Happy to send a PR for this if it'd be welcome.
2. Actually supporting a Worker-service designator is the bigger lifetime rework above, which really only Cloudflare can validate.

Context for why this matters: we hit this while prototyping local-dev support for remote Hyperdrive bindings (cloudflare/workers-sdk#14842). We're going with a local TCP bridge there rather than a Worker designator precisely because of this crash — which, I noticed afterwards, is the same conclusion the miniflare hyperdrive-proxy.ts code already reached (its comment notes the Worker-designator SIGSEGV). So this issue is really just about the defensive guard, not about unblocking that work.

[mack-erel]

I took a first pass at a defensive guard along the lines above. Two upfront caveats: it is unverified — I don't have a workerd build environment (no Bazel 9.1.1 / clang-format 18.1.8 here), so this has not been compiled, clang-formatted, or run against the repro — and it embeds a design question I'd want a maintainer to decide before it's worth polishing into a PR.

Approach: reject at config-link time, not connect time

The connect path (Hyperdrive::connectToDb → IoContext::getSubrequestChannel → IoChannelFactory::startSubrequest) deliberately hides the concrete service type behind WorkerInterface, so the service class isn't cleanly available there. It is available at the server layer, where the codebase already does kj::tryDowncast<WorkerService> to report config errors (e.g. the diskSvc binding check). So the guard resolves each hyperdrive designator in makeWorkerImpl's linkCallback and, if it downcasts to WorkerService, reports a config error:

Worker "worker-a"'s binding "HYPERDRIVE" is a Hyperdrive binding whose designator refers to
the service "worker-b", but that service is a Worker. Hyperdrive designators must reference an
`external` service, not a Worker.

External/network/disk services aren't WorkerService, so the downcast fails and the real Hyperdrive path (external.tcp) is untouched.

The design question

This is fail-fast at config load (errorReporter.addError → workerd refuses to start), consistent with how other invalid bindings are handled, and it prevents the SIGSEGV strictly earlier than connect time. But it's a different behavior from the connect()-handler precedent (global-scope.c++:232), which throws a runtime, JS-catchable error. If you'd rather this be catchable at .connect() time (worker keeps running, try/catch sees the error), the alternative is to substitute the hyperdrive channel with a stub whose startRequest/connect throws JSG_FAIL_REQUIRE (like InvalidConfigService) instead of erroring at link time.

I lean config-time (the designator type is statically knowable, unlike a missing handler), but this is really your call. Happy to build/verify/clang-format and open a proper PR once there's a preferred direction — or if it's easier for someone with the build set up to just take the patch and run with it, that's fine too.

Unverified patch (server.c++, +50/-5)

diff --git a/src/workerd/server/server.c++ b/src/workerd/server/server.c++
index 4b67bee..0eab842 100644
--- a/src/workerd/server/server.c++
+++ b/src/workerd/server/server.c++
@@ -4319,6 +4319,21 @@ struct FutureActorChannel {
   kj::String errorContext;
 };
 
+// Records a Hyperdrive binding's designator so that, once all services have been constructed, we
+// can verify (at link() time) that it references an `external` service rather than a Worker.
+//
+// Hyperdrive::connectToDb() resolves the designator into a subrequest channel and opens a raw
+// connection through it. For an `external` service this yields a self-contained stream that is
+// safe to hand back to the caller. For a Worker service, however, the returned stream is owned by
+// a WorkerInterface/IoContext that is torn down as soon as connectToDb() returns, producing a
+// cross-IoContext use-after-free that crashes the whole process with SIGSEGV (see
+// cloudflare/workerd#6901). We therefore reject such a configuration up front rather than let it
+// reach that path.
+struct FutureHyperdriveBinding {
+  kj::String serviceName;
+  kj::String errorContext;
+};
+
 struct FutureActorClassChannel {
   kj::OneOf<config::ServiceDesignator::Reader, kj::Own<IoChannelFactory::ActorClassChannel>>
       designator;
@@ -4350,6 +4365,7 @@ static kj::Maybe<WorkerdApi::Global> createBinding(kj::StringPtr workerName,
     kj::Vector<FutureActorChannel>& actorChannels,
     kj::Vector<FutureActorClassChannel>& actorClassChannels,
     kj::Vector<FutureWorkerLoaderChannel>& workerLoaderChannels,
+    kj::Vector<FutureHyperdriveBinding>& hyperdriveBindings,
     bool& hasWorkerdDebugPortBinding,
     kj::HashMap<kj::String, kj::HashMap<kj::String, Server::ActorConfig>>& actorConfigs,
     bool experimental) {
@@ -4572,8 +4588,8 @@ static kj::Maybe<WorkerdApi::Global> createBinding(kj::StringPtr workerName,
       for (const auto& innerBinding: wrapped.getInnerBindings()) {
         KJ_IF_SOME(global,
             createBinding(workerName, conf, innerBinding, errorReporter, subrequestChannels,
-                actorChannels, actorClassChannels, workerLoaderChannels, hasWorkerdDebugPortBinding,
-                actorConfigs, experimental)) {
+                actorChannels, actorClassChannels, workerLoaderChannels, hyperdriveBindings,
+                hasWorkerdDebugPortBinding, actorConfigs, experimental)) {
           innerGlobals.add(kj::mv(global));
         } else {
           // we've already communicated the error
@@ -4619,8 +4635,15 @@ static kj::Maybe<WorkerdApi::Global> createBinding(kj::StringPtr workerName,
     case config::Worker::Binding::HYPERDRIVE: {
       uint channel = static_cast<uint>(subrequestChannels.size()) +
           IoContext::SPECIAL_SUBREQUEST_CHANNEL_COUNT;
+      auto designator = binding.getHyperdrive().getDesignator();
+      // Remember this designator so link() can verify it points at an `external` service and not a
+      // Worker (which would cause a use-after-free crash; see cloudflare/workerd#6901).
+      hyperdriveBindings.add(FutureHyperdriveBinding{
+        .serviceName = kj::str(designator.getName()),
+        .errorContext = kj::str(errorContext),
+      });
       subrequestChannels.add(
-          FutureSubrequestChannel{binding.getHyperdrive().getDesignator(), kj::mv(errorContext)});
+          FutureSubrequestChannel{designator, kj::mv(errorContext)});
       return makeGlobal(Global::Hyperdrive{
         .subrequestChannel = channel,
         .database = kj::str(binding.getHyperdrive().getDatabase()),
@@ -4760,6 +4783,7 @@ struct Server::WorkerDef {
   kj::Vector<FutureActorClassChannel> actorClassChannels;
   kj::Vector<kj::Own<IoChannelFactory::RpcChannel>> rpcChannels;
   kj::Vector<FutureWorkerLoaderChannel> workerLoaderChannels;
+  kj::Vector<FutureHyperdriveBinding> hyperdriveBindings;
   bool hasWorkerdDebugPortBinding = false;
   kj::Array<FutureSubrequestChannel> tails;
   kj::Array<FutureSubrequestChannel> streamingTails;
@@ -5248,6 +5272,7 @@ kj::Promise<kj::Own<Server::Service>> Server::makeWorker(kj::StringPtr name,
   kj::Vector<FutureActorChannel> actorChannels;
   kj::Vector<FutureActorClassChannel> actorClassChannels;
   kj::Vector<FutureWorkerLoaderChannel> workerLoaderChannels;
+  kj::Vector<FutureHyperdriveBinding> hyperdriveBindings;
   bool hasWorkerdDebugPortBinding = false;
 
   auto confBindings = conf.getBindings();
@@ -5255,8 +5280,8 @@ kj::Promise<kj::Own<Server::Service>> Server::makeWorker(kj::StringPtr name,
   for (auto binding: confBindings) {
     KJ_IF_SOME(global,
         createBinding(name, conf, binding, errorReporter, subrequestChannels, actorChannels,
-            actorClassChannels, workerLoaderChannels, hasWorkerdDebugPortBinding, actorConfigs,
-            experimental)) {
+            actorClassChannels, workerLoaderChannels, hyperdriveBindings, hasWorkerdDebugPortBinding,
+            actorConfigs, experimental)) {
       globals.add(kj::mv(global));
     }
   }
@@ -5285,6 +5310,7 @@ kj::Promise<kj::Own<Server::Service>> Server::makeWorker(kj::StringPtr name,
     .actorChannels = kj::mv(actorChannels),
     .actorClassChannels = kj::mv(actorClassChannels),
     .workerLoaderChannels = kj::mv(workerLoaderChannels),
+    .hyperdriveBindings = kj::mv(hyperdriveBindings),
     .hasWorkerdDebugPortBinding = hasWorkerdDebugPortBinding,
 
     // clang-format off
@@ -5578,6 +5604,25 @@ kj::Promise<kj::Own<Server::WorkerService>> Server::makeWorkerImpl(kj::StringPtr
 
     result.subrequest = services.finish();
 
+    // Verify that every Hyperdrive binding's designator points at an `external` service rather than
+    // a Worker. Now that all services have been constructed we can resolve the designator and check
+    // its concrete type. Pointing a Hyperdrive binding at a Worker crashes the process with a
+    // use-after-free at connect() time (see cloudflare/workerd#6901), so we reject it as a
+    // configuration error. `external`, `network`, and `disk` services are not WorkerServices and so
+    // are unaffected by this check.
+    for (auto& hd: def.hyperdriveBindings) {
+      KJ_IF_SOME(svc, this->services.find(hd.serviceName)) {
+        KJ_IF_SOME(worker, kj::tryDowncast<WorkerService>(*svc)) {
+          (void)worker;
+          errorReporter.addError(kj::str(hd.errorContext, " is a Hyperdrive binding whose "
+              "designator refers to the service \"", hd.serviceName, "\", but that service is a "
+              "Worker. Hyperdrive designators must reference an `external` service, not a Worker."));
+        }
+      }
+      // If the service isn't found, the normal subrequest-channel lookup above already reported a
+      // configuration error for the missing service, so we don't report it again here.
+    }
+
     // Set up actor class channels
     auto actorClasses = kj::heapArrayBuilder<kj::Own<IoChannelFactory::ActorClassChannel>>(
         def.actorClassChannels.size() + actorClassNames.size());

[mack-erel]

I set up a workerd build locally and verified this end-to-end. Summary: the crash reproduces on a fresh build, a guard fixes it cleanly, and — interestingly — actually enabling a Worker-service designator needs more than the client-side lifetime fix.

Repro confirmed on a from-source build

Built //src/workerd/server:workerd (fastbuild) and ran the minimal repro from the issue. curl gets 200 "connected" and then the process dies with *** Received signal #11 during connection teardown — matching the "crash happens in deferred work, after the handshake" behavior noted above.

I tried the actual client-side lifetime fix — it removes the crash but data still doesn't flow

Mirroring connectImpl/asHttpClient (worker-interface.c++:117), I made Hyperdrive::connectToDb() keep the adapter + WorkerInterface alive on the returned stream:

auto httpClient = asHttpClient(kj::mv(service));
auto connectReq = httpClient->connect(kj::str(getHost(), ":", getPort()), headers, {});
auto status = co_await connectReq.status;
if (status.statusCode >= 200 && status.statusCode < 300) {
  co_return connectReq.connection.attach(kj::mv(httpClient));
}

Result (built + run): the SIGSEGV is gone — connect()/socket.opened resolve and the process survives — but bytes don't round-trip through a Worker-service target; the socket fails with a catchable Error: Network connection lost instead. So there's a second, target-side teardown issue (the newNeuterableIoStream/deferredNeuter + ctx.waitUntil() path in global-scope.c++:200-228) beyond the client-side Own I fixed. The external.tcp path is unaffected — I verified a real byte round-trip through an external.tcp designator still works with this change.

Takeaway: this looks like a guard fix, not a quick functional-enablement — making a Worker-service designator actually usable is more than a couple of lines, whereas preventing the crash is small and safe.

Two guard variants, both built and verified

Both compile and behave as expected on the from-source binary:

1. Config-time reject (refuse to start): detects a Worker designator at link time (kj::tryDowncast<WorkerService>, mirroring the existing diskSvc check) and calls errorReporter.addError. workerd exits with:
   Worker "worker-a"'s binding "HYPERDRIVE" is a Hyperdrive binding whose designator refers to the service "worker-b", but that service is a Worker. Hyperdrive designators must reference an 'external' service, not a Worker.
2. Runtime catchable (keep running): same detection, but swaps the hyperdrive channel for a stub that throws in startRequest (a dedicated stub rather than InvalidConfigService, whose getTokenMaybeSync is KJ_UNREACHABLE and would abort a live channel). workerd starts, .connect() throws a catchable error, and the process keeps serving — matching the existing "no connect handler" UX (global-scope.c++:232).

Both leave the external.tcp path untouched (external/network/disk aren't WorkerService, so detection never fires). Happy to open a PR with whichever you prefer — I'd lean toward the runtime-catchable variant since it matches the existing no-handler precedent, but config-time is the stricter/lower-risk option. I can clang-format and send it once you point me at the preferred direction.

(Context: this came out of prototyping local-dev support for remote Hyperdrive bindings, cloudflare/workers-sdk#14842 — which uses a local TCP bridge with an external.tcp designator precisely because, as the above confirms, a Worker-service designator isn't a viable path today.)

[robertgrace4546-sketch]

Dear 장효찬, Thank you for performing such a thorough investigation into issue #6901. Your breakdown of the SIGSEGV and the subsequent data flow issues is incredibly helpful. I agree with your assessment regarding the fix. Given the existing precedent for handling connection errors, please proceed with the runtime-catchable variant. It is preferable to allow the process to remain stable while throwing a catchable error rather than preventing startup entirely. Looking forward to your PR. Best regards, [Your Name]

…

-------- Original Email -------- From: "장효찬" ***@***.***> Sent: July 25, 2026 6:22:37 PM MST To: cloudflare/workerd ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [cloudflare/workerd] Hyperdrive.connect() crashes the whole process with SIGSEGV when the binding's designator points at a Worker service instead of an external service (Issue #6901) mack-erel left a comment (cloudflare/workerd#6901) I set up a workerd build locally and verified this end-to-end. Summary: the crash reproduces on a fresh build, a guard fixes it cleanly, and — interestingly — actually *enabling* a Worker-service designator needs more than the client-side lifetime fix. ### Repro confirmed on a from-source build Built `//src/workerd/server:workerd` (fastbuild) and ran the minimal repro from the issue. `curl` gets `200 "connected"` and then the process dies with `*** Received signal #11` during connection teardown — matching the "crash happens in deferred work, after the handshake" behavior noted above. ### I tried the actual client-side lifetime fix — it removes the crash but data still doesn't flow Mirroring `connectImpl`/`asHttpClient` (`worker-interface.c++:117`), I made `Hyperdrive::connectToDb()` keep the adapter + `WorkerInterface` alive on the returned stream: ```cpp auto httpClient = asHttpClient(kj::mv(service)); auto connectReq = httpClient->connect(kj::str(getHost(), ":", getPort()), headers, {}); auto status = co_await connectReq.status; if (status.statusCode >= 200 && status.statusCode < 300) { co_return connectReq.connection.attach(kj::mv(httpClient)); } ``` Result (built + run): **the SIGSEGV is gone** — `connect()`/`socket.opened` resolve and the process survives — **but bytes don't round-trip through a Worker-service target**; the socket fails with a catchable `Error: Network connection lost` instead. So there's a second, target-side teardown issue (the `newNeuterableIoStream`/`deferredNeuter` + `ctx.waitUntil()` path in `global-scope.c++:200-228`) beyond the client-side `Own` I fixed. The `external.tcp` path is unaffected — I verified a real byte round-trip through an `external.tcp` designator still works with this change. Takeaway: this looks like a guard fix, not a quick functional-enablement — making a Worker-service designator actually usable is more than a couple of lines, whereas preventing the crash is small and safe. ### Two guard variants, both built and verified Both compile and behave as expected on the from-source binary: 1. **Config-time reject** (refuse to start): detects a Worker designator at link time (`kj::tryDowncast<WorkerService>`, mirroring the existing `diskSvc` check) and calls `errorReporter.addError`. workerd exits with: `Worker "worker-a"'s binding "HYPERDRIVE" is a Hyperdrive binding whose designator refers to the service "worker-b", but that service is a Worker. Hyperdrive designators must reference an 'external' service, not a Worker.` 2. **Runtime catchable** (keep running): same detection, but swaps the hyperdrive channel for a stub that throws in `startRequest` (a dedicated stub rather than `InvalidConfigService`, whose `getTokenMaybeSync` is `KJ_UNREACHABLE` and would abort a live channel). workerd starts, `.connect()` throws a catchable error, and the process keeps serving — matching the existing "no connect handler" UX (`global-scope.c++:232`). Both leave the `external.tcp` path untouched (external/network/disk aren't `WorkerService`, so detection never fires). Happy to open a PR with whichever you prefer — I'd lean toward the runtime-catchable variant since it matches the existing no-handler precedent, but config-time is the stricter/lower-risk option. I can clang-format and send it once you point me at the preferred direction. (Context: this came out of prototyping local-dev support for remote Hyperdrive bindings, cloudflare/workers-sdk#14842 — which uses a local TCP bridge with an `external.tcp` designator precisely because, as the above confirms, a Worker-service designator isn't a viable path today.)

-- Reply to this email directly or view it on GitHub: #6901 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[mack-erel]

Gentle ping — it's been a few days, and both guard variants are built and verified locally, so this is only waiting on a direction.

@fhanau you implemented the inbound connect() handler in #6059, so you're likely closest to this code path — would you (or whoever owns Hyperdrive's connect plumbing) have a preference between the two guards described above? Briefly: (1) config-time reject (refuse to start with a config error) or (2) runtime catchable (start normally, .connect() throws a catchable error, process keeps serving — matching the existing "no connect handler" UX at global-scope.c++:232). Either is small and self-contained, and both leave the external.tcp path untouched. I can clang-format and open the PR the same day.

One clarification, since it affects how this thread reads: I don't believe the comment above is from a maintainer — the account has no other activity in this repo — so I haven't treated it as a decision. Happy to be corrected if it was official.