www: gzip_filter: gracefully handle socket ->write failures

Socket ->write failures are expected and common for TCP traffic,
especially if it's facing unreliable remote connections.  So
just bail out silently if our {gz} field was already clobbered
during the small bit of recursion we hit on ->write failures
from async responses.

This ought to fix some GzipFilter::zflush errors (via $forward
->close from PublicInbox::HTTP) I've been noticing on
deployments running -netd.  I'm still unsure as to why I hadn't
seen them before, but it might've only been ignorance on my
part...

Link: https://public-inbox.org/meta/20220802065436.GA13935@dcvr/

diff --git a/lib/PublicInbox/GzipFilter.pm b/lib/PublicInbox/GzipFilter.pm
index e37f1f76bd4a886431224ed38aa8a3f838cc50b1..c586d2f885dfe3bcdf3aff08f4ab87f7ac5275b7 100644 (file)
--- a/lib/PublicInbox/GzipFilter.pm
+++ b/lib/PublicInbox/GzipFilter.pm
@@ -149,10 +149,11 @@ sub zflush ($;$) {
        my $zbuf = delete $self->{zbuf};
        my $gz = delete $self->{gz};
        my $err;
-       if (defined $_[1]) {
+       if (defined $_[1]) { # it's a bug iff $gz is undef w/ $_[1]
                $err = $gz->deflate($_[1], $zbuf);
                die "gzip->deflate: $err" if $err != Z_OK;
        }
+       $gz // return; # not a bug, recursing on DS->write failure
        $err = $gz->flush($zbuf);
        die "gzip->flush: $err" if $err != Z_OK;
        $zbuf;