A read that fails partway through a response exits 1, not 8 #146

Exit 8 says the bytes did not arrive, and a supervisor is told to back off and try again on it. It only fires for a request that never got an answer, because that is the one place ErrTransport is attached: the retry loop in ccrawl/client.go. A read that fails partway through a response body has already got its answer, so it comes back as whatever the network handed over, unclassified, and classify in cli/classify.go leaves it as exit 1.

Caught live while timing a rank lookup:

$ time ccrawl rank host no-such-host-anywhere.invalid; echo $?
Read tcp [2001:ee0:...]:54947->[2600:9000:...]:443: read: no route to host.

real	1m17.585s
1

That is exit 1, the code the reference reserves for "the command itself is wrong". Nothing was wrong with the command. The route went away 77 seconds into a stream.

It hits the long commands hardest, which is where it matters most: the rank table is 262 million rows, the edge files are 7.7 GB, and a columnar scan is bigger still. Those are exactly the runs a supervisor is meant to restart, and exactly the runs most likely to lose a connection partway through, because they hold one open for minutes.

The documented supervisor pattern in the exit codes page stops on this rather than retrying:

case $? in
  8) sleep 3600; exec "$0" "$@" ;;
  *) exit 1 ;;
esac

Done when

• a read error partway through a body exits 8
• a status the server sent still exits 1, so 503 does not become retry forever
• the classification happens somewhere every command goes through, not per command