In gatt.go/Connect, once Scan has been called, it looks as though incoming adverts will create goroutines that eventually call fn to pass the advert data to Dial via ch. If multiple adverts arrive quickly, Dial will process the first, but the remaining adverts will block in fn on the send to ch.
Similarly, if Scan terminates for any reason other than a cancel, then we don't reach Dial and an incoming advert could block when trying to send to ch.
These blocked sends could leak goroutines, so Connect should probably close ch before the two return paths exit, and fn could defer a call to recover, in order to handle any panics when a is sent to a ch that's been closed.
In gatt.go/Connect, once Scan has been called, it looks as though incoming adverts will create goroutines that eventually call fn to pass the advert data to Dial via ch. If multiple adverts arrive quickly, Dial will process the first, but the remaining adverts will block in fn on the send to ch. Similarly, if Scan terminates for any reason other than a cancel, then we don't reach Dial and an incoming advert could block when trying to send to ch. These blocked sends could leak goroutines, so Connect should probably close ch before the two return paths exit, and fn could defer a call to recover, in order to handle any panics when a is sent to a ch that's been closed.