Incomplete block of responses with ERROR about libcody HOT 2 OPEN

Yeah, I've kind of left that underspecified. It wasn't clear what the best behaviour would be. I'm not quite sure what the GCC behaviour is.
It does seem reasonable that a truncated block of responses could be sent, once an ERROR response is to be sent, and it does seem reasonable that that causes a disconnection.

from libcody.

It does seem reasonable that a truncated block of responses could be sent, once an ERROR response is to be sent, and it does seem reasonable that that causes a disconnection.

Ok, I will proceed with this semantics then. Specifically, in certain cases I reply with ERROR, truncate the block (so this ERROR is the last response) and close both ends of the pipe.

I'm not quite sure what the GCC behaviour is.

I've tried to reply ERROR to HELLO (which is batched with the MODULE-REPO request), truncate the block and close the pipe. Here is the transcript:

g++-m -std=c++2a -fmodules-ts -fmodule-mapper=<> -x c++ -E -fdirectives-only -o hello.o.ii hello.cxx
  > HELLO 1 GCC '' ;
    MODULE-REPO
  < ERROR 'malformed request HELLO'
hello.cxx: error: failed mapper handshake malformed request HELLO
hello.cxx:3:10: error: cannot determine ‘#include’ translation of /home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/cassert: communication error:Unknown error -1

[... the same error for each include ...]

So while it seems to be ok with the truncated block, it doesn't seem to handle the closed pipe well. Perhaps an error response and closed communication should be interpreted as a fatal error?

from libcody.