[PATCH 1/4] www: gzip_filter: gracefully handle socket ->write failures

[Eric Wong <e@80x24.org>]

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/
---
 lib/PublicInbox/GzipFilter.pm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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;