This sounds a little like io.LimitWriter.
Most of our APIs use Readers, but any that return Writers might be helped by having a composable limit.

There was #46465 for a LimitedWriter

That seems to me like a specific use case for limiting the writing in the actual code, returning an io.EOF after a set amount of bytes.

This proposal is for testing, which allows defining any error to be returned.

Moving this over from #54548, which was closed as a dupe:

package io

func LimitWriter(w Writer, limit int64, err error) Writer {
	return &limitedWriter{w, limit, err}
}

type limitedWriter struct {
	w Writer
	n int64
	e error
}

func (lw *limitedWriter) Write(p []byte) (int, error) {
	if lw.n < 1 {
		return 0, lw.e
	}
	if lw.n < int64(len(p)) {
		p = p[:lw.n]
	}
	n, err := lw.w.Write(p)
	lw.n -= int64(n)
	return n, err
}

Cf. #51115

I think there are cases where one ends up using a limit reader, but conceptually what you really want is a limit writer. You don't really care if the request you're copying is consumed some kind of streaming processor, but you don't want to copy more than N bytes into memory or onto disk. LimitWriter would be useful for those cases.

I have also run into a variation on this theme, where something like this seemed very clean:

var b bytes.Buffer
for _, job := range jobs {
    run( job.cmd, LimitWriter(&b, job.limit))
}

because a Write error implied the job had gone haywire, and the run function could use that as a reason to kill the process. I tried LimitReader, io.Pipe things first but the elaborations to get kill-on-Write were tricky and indirect, I felt like LimitWriter really was the right abstraction.

I agree that an io.LimitWriter would be useful, but I don't think one that yields custom errors should be part of io.

Having io.LimitWriter(w io.Writer, limit int64, err error) io.Writer as proposed by @carlmjohnson would fit both use cases (production and tests) but would also require all the call sites for production code to pass the expected error, which I don't see any case where it wouldn't be io.EOF as it seems weird to me that a LimitWriter would return a different error.

Another option is to have the type public like LimitedReader:

package io

func LimitWriter(w Writer, limit int64) Writer {
	return &LimitedWriter{W: w, N: limit, Err: EOF}
}

type LimitedWriter struct {
	W Writer  // underlying writer
	N int64   // max bytes remaining
	Err error // error to be returned once limit is reached
}

func (lw *LimitedWriter) Write(p []byte) (int, error) {
	if lw.N < 1 {
		return 0, lw.Err
	}
	if lw.N < int64(len(p)) {
		p = p[:lw.N]
	}
	n, err := lw.W.Write(p)
	lw.N -= int64(n)
	return n, err
}

This would allow the same pattern as io.LimitReader and also allow tests, like the use case I proposed originally, to instantiate the structure directly:

&io.LimitedWriter{W: originalWriter, N: 100, Err: io.ErrClosedPipe}

I'd be ok with either, but IMHO it would be better to have ioutil.ErrWriter and io.LimitWriter as two separate things mirroring ioutil.ErrReader and io.LimitReader. In this case the io.LimitWriter would probably be a separate proposal.

I don't think io.EOF makes sense in the context of a writer. Maybe io.ErrShortWrite could be the default.

True, I was thinking of the default for LimitReader. io.ErrShortWrite makes a lot more sense.