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/

1 files changed, 2 insertions, 1 deletions

diff --git a/lib/PublicInbox/GzipFilter.pm b/lib/PublicInbox/GzipFilter.pm
index e37f1f76..c586d2f8 100644
--- 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;