Subject: Re: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails

From: Eli Zaretskii <[email-masked]>
Date: Mon, 30 Jun 2025 15:52:45 +0300

> From: Robert Pluim <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>,  [email-masked]
> Date: Mon, 30 Jun 2025 10:01:50 +0200
> 
> >>>>> On Sun, 29 Jun 2025 17:22:36 -0400, Shawn Henson <[email-masked]> said:
> 
>     >> I wonder what Emacs does for ":nowait t" without async DNS, when the
>     >> connect fails. Iʼd expect it to call the sentinel with a "failed"
>     >> status.
> 
>     Shawn> Is there a trivial way to test this?
> 
> Not without recompiling Emacs, but Iʼve just tested it. It results in
> an immediate error return from `make-network-process', no process is
> created, and the sentinel is not called. Thatʼs all as expected (now
> that Iʼve had my coffee 😀).

Right.

> Eli, what can we do here? Whether or not Emacs is using getaddrinfo_a
> should not affect the behaviour here, although having a process be
> created is unavoidable, since weʼre deferring the DNS lookup.

If we want the same behavior, we should signal an error when DNS look
up fails.

> The docstring for `make-network-process' says this in the :nowait
> section:
> 
>     the sentinel function will be called with second arg matching
>     "open" (if successful) or "failed" when the connect completes.
> 
> Pedantically, the `connect' syscall is not completed, since we never
> attempt it because of the DNS failure. But the "attempt to connect to
> the remote host" has completed, unsuccessfully, so we should call the
> sentinel (and not call it when the process is deleted).

But then the behavior will not be like we get when getaddrinfo_a is
unavailable, no?

Technically, we have no process object in this case; the fact that we
create one is an implementation detail.  I'd even go as far as saying
that this "process" should not be exposed to Lisp.