I'm not sure what guarantees the race detector makes about what it's definitely able to detect. Maybe not reporting a race when the curls were done sequentially is a feature, in that there was not actually a race (but could be if the requests arrived at the same time). Or maybe detecting such "potential races" could be a feature request.

It seems the following program also doesn't report a race (which likely doesn't happen if you wait enough seconds to be sure the first goroutine completed before providing stdin):

package main

import "fmt"

func main() {
	counter := 0

	go func() {
		counter++
		fmt.Println(counter)
	}()

	fmt.Scanln(new(string))

	go func() {
		counter++
		fmt.Println(counter)
	}()

	// Output (with -race):
	// 1
	// a
	// 2
}

CC @ianlancetaylor, @neild.

The race detector does make an effort to detect potential races. Usually when the race detector fails to report a race it is because there is an unexpected synchroniation/serialization in a library.

The later example above will indeed report a race if run as ./x < /dev/null or as echo hi | ./x. Otherwise I think it's being effectively synchronized by the runtime I/O code. That may also be what is happening in the earlier example, I'm not sure.

CC @dvyukov

All real races should be eventually detectable. In this case you play role of synchronization since you run curl sequentially ;)
If you write a stress test where the handler is invoked concurrently, the race should be detected eventually.

As Ian pointed, the false negative happens due to induced io synchronization:

src$ egrep "race\.(Acquire|Release)" syscall/*.go
syscall/syscall_unix.go:			race.Acquire(unsafe.Pointer(&ioSync))
syscall/syscall_unix.go:		race.ReleaseMerge(unsafe.Pointer(&ioSync))
syscall/syscall_unix.go:			race.Acquire(unsafe.Pointer(&ioSync))
syscall/syscall_unix.go:		race.ReleaseMerge(unsafe.Pointer(&ioSync))
syscall/syscall_unix.go:		race.ReleaseMerge(unsafe.Pointer(&ioSync))
syscall/syscall_windows.go:		race.Acquire(unsafe.Pointer(&ioSync))
syscall/syscall_windows.go:		race.ReleaseMerge(unsafe.Pointer(&ioSync))

Removing that will lead to false positives and we prefer to err on side of false negatives.

It may be possible to restructure http package to run the handler in unsynchronized goroutines. But not sure if it will work b/c the goroutine will still need to accept/read/receive before the handler and send after the handler.
Otherwise my vote for #WAI

Thanks, closing as there is nothing we can reasonably do here.

thanks for clarification