inboxwritable: drop {-importer} cyclic reference

InboxWritable caching the result of ->importer leads to a
circular references with returned (V2Writable|Import) object
holds onto the calling InboxWritable object.

With public-inbox-watch, this leads to a memory leak if a user
is reloading via SIGHUP after a message is imported (it would
only become noticeable with SIGHUPs after every message imported).

I would not expect anybody to to notice this in real-world
usage.  I only noticed this since I was making -xcpdb suitable
for long-lived process use (e.g. "mod_perl style") and a flock
remained unreleased on v1 inboxes after resharding.

WatchMaildir (used by -watch) already handles caching of the
importer object itself, and all of our other real-world uses of
->importer are short-lived or designed for batch scripts, so
there's no need to cache the importer result internally.

1 files changed, 2 insertions, 2 deletions

diff --git a/lib/PublicInbox/Admin.pm b/lib/PublicInbox/Admin.pm
index e9fb5d6f..d2a0d06b 100644
--- a/lib/PublicInbox/Admin.pm
+++ b/lib/PublicInbox/Admin.pm
@@ -199,12 +199,12 @@ invalid indexlevel=$indexlevel (must be `basic', `medium', or `full')
 }
 
 sub index_inbox {
-        my ($ibx, $opt) = @_;
+        my ($ibx, $im, $opt) = @_;
         my $jobs = delete $opt->{jobs} if $opt;
         if (ref($ibx) && ($ibx->{version} || 1) == 2) {
                 eval { require PublicInbox::V2Writable };
                 die "v2 requirements not met: $@\n" if $@;
-                my $v2w = eval { $ibx->importer(0) } || eval {
+                my $v2w = $im // eval { $ibx->importer(0) } || eval {
                         PublicInbox::V2Writable->new($ibx, {nproc=>$jobs});
                 };
                 if (defined $jobs) {