GNU bug report logs -
#78920
30.1; Process sentinel is not called when DNS lookup fails
Previous Next
Full log
View this message in rfc822 format
> Date: Sun, 29 Jun 2025 03:59:17 -0400
> Cc: 78920 <at> debbugs.gnu.org
> From: Shawn Henson <shawn <at> shenso.name>
>
>
> On 6/29/25 1:13 AM, Eli Zaretskii wrote:
> >> Date: Sat, 28 Jun 2025 18:04:07 -0400
> >> From: Shawn Henson <shawn <at> shenso.name>
> >>
> >> I was testing a function of mine which wraps `url-retrieve', and I found
> >> myself confused that my callback was not being reached with bad
> >> host names, and upon debugging discovered the process sentinel was not
> >> being called at all. Using the Lisp debugger added further confusion
> >> because the process status of the returned buffer would be "failed", but
> >> this was not the case during normal evaluation due to race conditions.
> >>
> >> You can reproduce this with make-network-process:
> >>
> >> ```
> >> (let ((my-test-proc (make-network-process :name "dns-fail-test"
> >> :buffer "dns-fail-test-buf"
> >> :host "thisisnotarealhostname"
> >> :service 80
> >> :nowait t
> >> :sentinel (lambda (process event)
> >> (print event)))))
> >> (message "process status: %s" (process-status my-test-proc)))
> >> ```
> >>
> >> After evaluation, the *Messages* buffer includes:
> >>
> >> ```
> >> process status: connect
> >> ```
> > What happens if you use ':nowait nil' instead? Is the sentinel get
> > called?
>
> In this case, an error is signaled upon evaluating the function:
>
> ```
> Debugger entered--Lisp error: (error "thisisnotarealhostname/80 Name or
> service not known")
> make-network-process(:name "dns-fail-test" :buffer
> "dns-fail-test-buf" :host "thisisnotarealhostname" :service 80 :nowait
> nil :sentinel #f(lambda (process event) [t] (print event)))
> ```
>
> This seems in line with the function documentation, which seems to
> confirm the sentinel should be
> called when it is 't', which is the case for `url-retrieve'.
>
> ```
> :nowait BOOL -- If NOWAIT is non-nil for a stream type client
> process, return without waiting for the connection to complete;
> instead, the sentinel function will be called with second arg matching
> "open" (if successful) or "failed" when the connect completes.
> Default is to use a blocking connect (i.e. wait) for stream type
> connections.
> ```
Yes, but when the problem is with the DNS resolution, there's no
connection, and technically no running process. The "failed" status
is never reached because of that.
Robert, WDYT?
This bug report was last modified 5 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.