Main Issue: #26815

Motivation

Schema storage closes an opened BookKeeper read handle only when the entry read succeeds. A failed read bypasses cleanup and can leave the handle and its metadata listener retained.

Modifications

• Close an opened handle after the read/decode attempt, including asynchronous failures and synchronous exceptions.
• Wait for the close callback before completing the operation.
• Preserve the original read/decode error when cleanup also fails, attaching the close error as a suppressed exception to the underlying cause. A close failure after a successful read still fails the operation.

Failed reads remain failed; this change does not introduce retries or modify BookKeeper watch registration.

Verifying this change

• Make sure that the change passes the CI checks.

Local validation passed as described below. Full CI validation is still pending.

BookkeeperSchemaStorageReadHandleTest covers nine outcomes through the public storage read path. Tests delay read/close callbacks to check ordering, use malformed serialized bytes for decoding failures, assert exactly one close after a successful open, and verify both the primary and suppressed errors. The failed-open control verifies that no read or close is attempted.

With the tests unchanged and only the production changes removed (base 1046481c970067cbca9c80a25a98257b9179a3da), four cases fail: three read-failure paths never invoke close, and a combined decode/close failure loses the decode error. The other five are compatibility controls that pass on both versions.

The two combined-failure cases also fail against the initial PR implementation: the close error was attached to an asynchronous wrapper and was lost when the caller unwrapped the original error. The updated implementation preserves it on the underlying cause.

With the fix restored, all nine cases and 19 related existing tests pass (28 total), along with quickCheck:

./gradlew :pulsar-broker:test \
  --tests '*BookkeeperSchemaStorageReadHandleTest' --tests '*BookkeeperSchemaStorageTest' \
  --tests '*SchemaServiceTest' \
  -PtestRetryCount=0 -PtestFailFast=false -PtestMaxParallelForks=1 --max-workers=2 quickCheck

Does this pull request potentially affect one of the following parts:

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment