Please write a self-contained bug report that isn't dependent on reading a whole thread elsewhere.

What is the problem?

The problem is that if you have a Server object which can be started and stopped and is restartable (which appears to be how http.Server{} is meant), then an async shutdown signal like Close() which closes anything the server does at the moment it takes the lock can't really be sure which Serve() invocation(s) it actually closed since their might be Serve() invocations called by not yet having effect.

It is of course a matter of subjective intention how it's meant to work and could be documented, but it should probably be a conscious decision.

If http.Serve was not restartable (or only restartable after at Reset() method had been called) then you would know in the above example that waiting would not deadlock.
But since it's restartable any Close() before Serve() takes the mutex lock is effectively a dropped message - has no effect. So whether or not you end up stopping a Serve() depends on timing. (as illustrated by adding a Sleep() to the Serve() call.

So (in effect) - if you hook http.Server.Close() up on an OS signal like SIGTERM then those signals would some times be lost due to them arriving at a point in a restart loop where there just was another Close() having closed the server and the restart already in progress but no listeners having been tracked yet.
Say you have SIGHUP triggering a Close() and a new Serve(), but have SIGINT triggering a Close() and and exit. Then a SIGINT arriving directly after at SIGHUP would exit while a server was still running since it's Close() invocation would not do anything.

One proposed alternative semantic would be to be able to associated a Serve() invocation with a context and having Close() cancel that context. Then you would always know exactly which Serve() invocations you closed ... of course that could be a complex API solution given the API promise.

This might be deliberately intended behavior ...

PS: Thanks to Nick Patavalis for bringing up the question on the list and figuring out most of the implications.

Close is a really strong hammer. It interrupts requests still being processed. You can wire it up how you want to wire it up. Yes, it'll probably involve some coordination and synchronization on your side.

Shutdown is a much softer tool. But it also requires some coordination, depending on what you want to do.

If you want to close a specific Server.Serve, you already can: retain the net.Listener you pass to it, and call Close on it yourself.

There won't be any one magical answer for everybody that doesn't involve some code.

I'm going to close this because I'm not sure what there is to do here. I'm probably not understanding something still.

Keeping the listener and calling Close() on it to cancel a specific Serve() invocation would solve part of the problem, yes ... however the result from the caller of Serve() viewpoint would be different in the ErrServerClosed would not be returned. .. which ties into #4373