Consider the following:

exchange.getResponseHeaders().put(Headers.CONTENT_LENGTH, "1");
OutputStream out = exchange.getOutputStream();
out.write(65);
out.flush(); // Always throws IOException(Stream is closed)
out.close();

UndertowOutputStream is aware of the Content-Length header, and within 'updateWritten' will helpfully write data to the response once the last byte is written to the stream. However, this is done by UndertowOutputStream closing itself, which isn't obvious to developers using the OutputStream implementation. In the case above, flush should be a no-op because the stream has internally already flushed data (which is entirely reasonable), however it should not throw because the stream itself hasn't been closed, despite the state change internally.

I think there are two potential ways we could resolve this:
1. UndertowOutputStream can track another piece of data: 'close-has-been-invoked' in addition to 'closed'. Flush could throw if an external caller has invoked close, but not in the case the underlying resource has been closed because it's finished. This path would be very precise, but also more complex than perhaps necessary.
2. UndertowOutputStream.flush can no-op in the case that the stream is already closed, and no remaining data is buffered. This is simpler to implement, and matches the behavior of ServletOutputStreamImpl.

I'll plan to create a PR implementing the second option as I think internal consistency between the two blocking streams is valuable, but I'm happy do implement either based on feedback.
This issue is somewhat similar to UNDERTOW-2189, which reminded me to file an issue