Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Must not wrap io.EOF

Open Beginner friendly
#561 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
go
Domain
networking

Research direction

Start at errd.Wrap and its use in Conn.reader, then review the Go io.EOF documentation cited in the issue. Reproduce the wrapped-EOF case and check the project's existing tests; done means EOF remains directly comparable while other errors retain context.

Written by the indexing model from the issue text.

Description

From the Go docs:

// EOF is the error returned by Read when no more input is available.
// (Read must return EOF itself, not an error wrapping EOF,
// because callers will test for EOF using ==.)
// Functions should return EOF only to signal a graceful end of input.
// If the EOF occurs unexpectedly in a structured data stream,
// the appropriate error is either [ErrUnexpectedEOF] or some other error
// giving more detail.
var EOF = errors.New("EOF")

however, Conn.reader (and probably others) wrap io.EOF:

func (c *Conn) reader(ctx context.Context) (_ MessageType, _ io.Reader, err error) {
	defer errd.Wrap(&err, "failed to get reader")


// Wrap wraps err with fmt.Errorf if err is non nil.
// Intended for use with defer and a named error return.
// Inspired by https://github.com/golang/go/issues/32676.
func Wrap(err *error, f string, v ...any) {
	if *err != nil {
		*err = fmt.Errorf(f+": %w", append(v, *err)...)
	}
}

This leads to errors such as https://github.com/hashicorp/yamux/pull/167.

I'd propose special-casing Wrap to check for io.EOF and would be happy to open a PR.

Dominant language
Go
Stars
5.5k
Forks
377
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from coder/websocket

All issues in coder/websocket

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.