Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 62.62%. Comparing base (93c57b6) to head (1c3c9b5).
⚠️ Report is 1660 commits behind head on master.

@@            Coverage Diff             @@
##           master    #7517      +/-   ##
==========================================
+ Coverage   55.70%   62.62%   +6.92%     
==========================================
  Files         224      274      +50     
  Lines       10016    18318    +8302     
==========================================
+ Hits         5579    11472    +5893     
- Misses       3978     6178    +2200     
- Partials      459      668     +209     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Conflict caused by #7562 but I think this PR is definitely worth doing still. Please rebase when you have a moment, thanks!

If I read correctly, dns.Server.Shutdown / ShutdownContext already have protections to be safe for concurrent calls: https://github.com/miekg/dns/blob/294d37389cccc53250740798dde72a0c1810be2a/server.go#L398-L448

Need to understand whether stopOnce is necessary.

I ran similar tests as in #7314, which has the stacktrace visible. There's also TestReloadConcurrentRestartAndStop which you can use for validation, if the stopOnce appears unnecessary. 👍

I struggle how to make TestStopIsIdempotent useful. It doesn't seem to test anything atm.

Yeah +1 for removing it now with dnsWg gone

How about a test that starts a server, sets a very short graceTimeout, calls Stop(), and asserts context.DeadlineExceeded? Should exercise the timeout path and verify the deadline is propagated properly.

I'm not sure that can reliably work unless there is an active TCP connection. But assuming it does, how does this verify that Stop is idempotent?

Yeah this would be a new test. I would remove the idempotency one with dnsWg now gone. And stopOnce structurally guarantees that Stop() is idempotent, so not much value in testing it anymore. Instead this new test would focus on observing the context timeout. I guess the test directory would be the best place for an e2e test like that.

Which behavior is preferred for Stop's error: return the error on all calls or return the error on the first call only?

@thevilledev Is this the test you had in mind? The biggest downside is it uses default value for graceTimeout which is 5 seconds.

Yeah I think that's the right idea. Although I missed the fact that we can't change graceTimeout. The reflect for private fields is probably the most brittle part.

What do you think of an in-package test instead? I did the following test using your blocking struct in core/dnsserver/server_test.go and seems to work quite well:

func TestGracefulStopTimeout_Internal(t *testing.T) {
	p := new(blocking)
	cfg := testConfig("dns", p)

	s, err := NewServer("127.0.0.1:0", []*Config{cfg})
	if err != nil {
		t.Fatalf("NewServer failed: %v", err)
	}

	// Shorten the graceful timeout
	s.graceTimeout = 500 * time.Millisecond

	pc, err := net.ListenPacket("udp", "127.0.0.1:0")
	if err != nil {
		t.Fatalf("ListenPacket failed: %v", err)
	}
	defer pc.Close()

	go s.ServePacket(pc)
	udp := pc.LocalAddr().String()

	// Block the handler
	p.lock.Lock()
	defer p.lock.Unlock()

	m := new(dns.Msg)
	m.SetQuestion("example.com.", dns.TypeA)

	// Readiness loop to avoid flakiness
	deadline := time.Now().Add(2 * time.Second)
	for {
		_, err := dns.Exchange(m, udp)
		if err == nil || time.Now().After(deadline) {
			break
		}
		time.Sleep(10 * time.Millisecond)
	}

	err = s.Stop()

	if !errors.Is(err, context.DeadlineExceeded) {
		t.Fatalf("expected context.DeadlineExceeded, got %v", err)
	}
}

Which behavior is preferred for Stop's error: return the error on all calls or return the error on the first call only?

IMO returning it only on the first call would hide failures from later callers which kinda complicates err handling. With sync.Once subsequent calls get the stored error from the first Stop() call.

IIUC the socket is ready and the only source of flakiness is go s.ServePacket(pc). Since the dns.Exchange already uses a timeout of 2 seconds, do you think this loop is necessary?