[BUG] If `deadline` argument to `WriteControl` is `deadline.IsZero()` then 1000 hours (~41 days) are used as unexpected and undocumented fallback

[JannikGM]

[BUG] If `deadline` argument to `WriteControl` is `deadline.IsZero()` then 1000 hours (~41 days) are used as unexpected and undocumented fallback

[jaitaiwan]

Champion @JannikGM thank you. I'm taking a look at this now.

[jaitaiwan]

Nothing in the RFC seems to indicate any sane value for this. I don't know of any websocket extensions that need to be accounted for in any changes here.

It appears to me that this code is used in both client and server connections, so this probably is a more important function when it comes to clients being unable to write to the server.

Based on that information I think that the following actions should be taken:

1. The default is documented as a warning
2. Any examples should be updated to include setting this deadline to a sane standard
3. This issue should be left open and marked for a v2 as changing this could be a nasty surprise for implementors that don't know about this

[GreenMarmot]

In the Go ecosystem, a zero value for deadline is usually taken to mean no deadline, not a deadline at the beginning of time. We know that's the intent here because the function sets the deadline on the network connection. A zero deadline on the network connection means no deadline.

A deadline in 41 days is not the same thing as no deadline, but it's a good approximation for most applications. Close the gap between what this package does and the expectations for deadlines by using the following code:

if deadline.IsZero() {
	<-c.mu
} else {
	d = time.Until(deadline)
	if d < 0 {
		return errWriteTimeout
	}
	select {
	case <-c.mu:
	default:
		timer := time.NewTimer(d)
		select {
		case <-c.mu:
			timer.Stop()
		case <-timer.C:
			return errWriteTimeout
		}
	}
}

With timeout of 41 days, it's unlikely that an application developer wrote code to rely on the undocumented timeout. It's not practical to test.

To trigger the 41 day timeout, another goroutine must be blocked for 41 days on write to the network connection. I'd expect the blocked write on a network connection to return an error before the 41 days elapses.

You will not break anything by updating to the code above. There will be no nasty surprises. You will not fix a problem that comes up in practice, but the code will be more correct and it will feel good to remove that weird constant from the code.