[fix][txn] Fix PendingAckHandleImpl when pendingAckStoreProvider.checkInitializedBefore failed

[tjiuming]

Motivation

When initialize PendingAckHandleImpl, it will call

        pendingAckStoreProvider.checkInitializedBefore(persistentSubscription)
                .thenAccept(init -> {
                    if (init) {
                        initPendingAckStore();
                    } else {
                        completeHandleFuture();
                    }
                });

And pendingAckStoreProvider.checkInitializedBefore(persistentSubscription) will call MetadataStore#asyncExists(String ledgerName)

If MetadataStore no available at that time, it may returns an exception.
If we don't handle the exception when call

pendingAckStoreProvider.checkInitializedBefore(persistentSubscription)

the PendingAckHandleImpl cannot completed.
addConsumer will always block, the Consumer created in PersistentTopic will never close and finished.

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository: tjiuming#14

[github-actions]

@tjiuming Please add the following content to your PR description and select a checkbox:

- [ ] `doc` <!-- Your PR contains doc changes -->
- [ ] `doc-required` <!-- Your PR changes impact docs and you will update later -->
- [ ] `doc-not-needed` <!-- Your PR changes do not impact docs -->
- [ ] `doc-complete` <!-- Docs have been already added -->

[congbobo184]

Good catch! when PendingAckHandle recovery fails, it will not recover again, the consumer still can't connect to the broker. we should find out a way to solve this problem, if recovery fails, remove the subscription from PersistentTopic, and consumer connect again will reinit this sub.

[tjiuming]

Good catch! when PendingAckHandle recovery fails, it will not recover again, the consumer still can't connect to the broker. we should find out a way to solve this problem, if recovery fails, remove the subscription from PersistentTopic, and consumer connect again will reinit this sub.

Yes, it does a problem.
I've read the code, if PendingAckHandleImpl relay failed, it won't do it again. And the client couldn't create Consumer for the subscription.
I'll create another PR to fix it.

[codecov-commenter]

Codecov Report

Merging #18859 (955e1fe) into master (d30e86c) will increase coverage by 0.01%.
The diff coverage is 31.25%.

@@             Coverage Diff              @@
##             master   #18859      +/-   ##
============================================
+ Coverage     47.92%   47.93%   +0.01%     
- Complexity    10679    10688       +9     
============================================
  Files           703      703              
  Lines         68831    68856      +25     
  Branches       7378     7382       +4     
============================================
+ Hits          32988    33009      +21     
- Misses        32119    32177      +58     
+ Partials       3724     3670      -54     

Flag	Coverage Δ
unittests	47.93% <31.25%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...er/loadbalance/impl/PulsarResourceDescription.java	11.11% <0.00%> (-1.71%)	⬇️
...nsaction/pendingack/impl/PendingAckHandleImpl.java	51.73% <50.00%> (-0.11%)	⬇️
...ain/java/org/apache/pulsar/broker/rest/Topics.java	0.00% <0.00%> (-100.00%)	⬇️
.../pulsar/broker/rest/RestMessagePublishContext.java	0.00% <0.00%> (-77.78%)	⬇️
...ker/resourcegroup/ResourceQuotaCalculatorImpl.java	4.16% <0.00%> (-62.50%)	⬇️
...r/resourcegroup/ResourceUsageTransportManager.java	42.85% <0.00%> (-57.15%)	⬇️
...lsar/broker/service/StickyKeyConsumerSelector.java	50.00% <0.00%> (-50.00%)	⬇️
...ersistentStickyKeyDispatcherMultipleConsumers.java	0.00% <0.00%> (-50.00%)	⬇️
...java/org/apache/pulsar/broker/rest/TopicsBase.java	0.00% <0.00%> (-40.67%)	⬇️
...e/HashRangeExclusiveStickyKeyConsumerSelector.java	0.00% <0.00%> (-40.00%)	⬇️
... and 78 more