I want to change this to %d, but it was %v before so let's maybe leave it that way 😂

Better safe than sorry 😅

If we need this, I'd still like to avoid introducing new exported error types. I think a sentinel error would be better here as they're a bit easier to use as well via errors.Is.

var ErrMessageTooBig = errors.New("websocket: message too big")

That also doesn't stop us from adding context (limit) via:

err = fmt.Errorf("%w: %w", ErrMessageTooBig, context)

I've made the change, although I'm concerned about the possibility of breaking downstream consumers if they rely on the current error message

I understand your concern. However, string matching on errors is never recommended and consumers should expect it to be brittle, especially when it contains a number that may change. That said, we could retain the error format meaning if consumers use "contains" rather than "==" they would be fine:

fmt.Errorf("%w: read limited at %d bytes", ErrMessageTooBig, c.msgReadLimit.Load())

I've been giving this some more thought. And I really dislike introducing YAAS (yet another API surface?).

• We already have StatusMessageTooBig
• We already close the connection
• We call c.writeError which calls c.writeClose and returns an error.

Why don't we just do:

msg := fmt.Sprintf("read limited at %d bytes", c.msgReadLimit.Load())
err := c.writeClose(StatusMessageTooBig, msg)
return err

This will return a CloseError, but that is actually more correct IMO. The status of CloseError can be checked for StatusMessageTooBig. Thoughts?

Calling .Error() on the CloseError will return status = 1009 and reason = read limited at N bytes. This is good enough for a string contains but if we really need to do 100% backwards compatibility. We can create a private error type that stringifies the backwards compatible error, but implements custom methods for error is/as to match on CloseError. I don't think we need to go that far though.

Actually looks like I skimmed writeClose, it doesn't return the CloseError, but constructing it would be an option.

But maybe returning CloseError from read would be too unexpected (may seem like peer close), so sentinel approach is perhaps best after all.

Could you also update the code-path in ws_js.go?