[resolver] invalid concurrent query count is misleading

During runtime, we sometimes see the following error message in journalctl:

dockerd: time="2020-04-16T13:25:59.896906044+02:00" level=error msg="[resolver] invalid concurrent query count"

This leads to the assumption, that something with an internal resolver is wrong and there is a DNS issue. In fact, when checking the affected node and all containers running on that node when this error occurs, we can not detect any DNS issue at all.

Tested by: Running DNS queries inside the container and on the host directly.

I tried understanding the code where this error message is coming from:
https://github.com/moby/libnetwork/blob/master/resolver.go

For me, it looks like as soon as a query was processed, a counter for concurrent DNS queries is decreased by one:

func (r *resolver) forwardQueryEnd() {
	r.queryLock.Lock()
	defer r.queryLock.Unlock()

	if r.count == 0 {
		logrus.Error("[resolver] invalid concurrent query count")
	} else {
		r.count--
	}
}

And if the concurrent query count is already 0, the counter can not be decreased any more, hence an error is thrown. In my understanding, this has no effect on the function of the resolver, the queries still work. So throwing an error that there is an invalid concurrent query count is misleading. It leads to the assumption that something is not working right, although it just means that there are no more queries left to be processed.

Can someone please confirm that I am not totally wrong here?
If I'm right, I would like to suggest that the error message is adapted slightly, helping sys admins to judge the "error" better. Or maybe switch the level from "error" to "info" or not log something at all.

docker info:

Client:
 Debug Mode: false

Server:
 Containers: 29
  Running: 27
  Paused: 0
  Stopped: 2
 Images: 845
 Server Version: 19.03.5
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local local-persist
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: active
  NodeID:
  Is Manager: true
  
  Orchestration:
   Task History Retention Limit: 5
  
  Autolock Managers: false

 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc version: 425e105d5a03fabd737a126ad93d62a9eeede87f
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 3.10.0-1062.9.1.el7.x86_64
 Operating System: Red Hat Enterprise Linux Server 7.7 (Maipo)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 31.26GiB
 Debug Mode: false

 Experimental: true

Start with resolver.go and inspect forwardQueryEnd, especially the handling of r.count and the "invalid concurrent query count" log. Confirm whether this condition affects resolver operation, then determine the appropriate message or log level. Done means the log no longer misleadingly suggests a DNS failure while preserving visibility into a genuine counter problem.