Context: publisher-owned async work can deadlock close (close/publish dependency cycle)

[marcio-absmartly]

Split out of #11 review discussion so it can get its own design and review.

Problem

Context.closeAsync() awaits every in-flight publish before finalizing. If work owned by a ContextPublisher calls closeAsync() (or close()) and only completes its transport future after that close settles, the two futures wait on each other and neither ever completes. The context is left permanently closing.

Reproduced by @Pedro-Revez-Silva with a publisher that starts a worker thread, returns an incomplete transport future, has the worker call context.closeAsync(), and completes the transport only once close finishes. An executor callback reaches the same state. The direct same-thread variant (publisher calls closeAsync() inline) is the degenerate case of the same cycle.

This is pre-existing on main, not introduced by #11.

Why the obvious fix does not work

A same-thread guard was attempted on #11 and reverted (436ba37). Rejecting close when the calling thread is inside publish() only catches the inline case; any delegated thread walks straight past it. Chasing the worker thread moves the hole rather than closing it, and the tolerance machinery built around it (same-thread exclusion, reopening closed_/closing_ from the publish failure path, pending-count rechecks before finalization) produced its own defects: close completing successfully while isClosed() == false with events queued, a late publisher failure resurrecting an already-closed context and emitting a second Close, and restoration clearing closing_ letting a concurrent close overwrite closingFuture_.

Suggested direction

Attack the dependency rather than the callback, per @Pedro-Revez-Silva: redesign the close/publish dependency so publisher-owned asynchronous work cannot form this cycle.

Close only awaits in-flight publishes because a failed publish restores its batch (pendingCount_.addAndGet(...) in flush()'s failure handler) and close must not finalize with events pending. Break that edge and no thread — inline, worker, or executor — can form the cycle:

• have restoration treat events as undeliverable once close has finalized, rather than requiring close to wait; or
• give close a bounded wait, after which it finalizes and reports the undelivered batch honestly.

Either removes the need for a contract, for reentrancy detection, and for the failure modes above.

Constraints

• Java 1.6 source/bytecode floor (Android); java8.util.concurrent.CompletableFuture, anonymous inner classes only in main/java.
• Must preserve the invariant Java SDK: All tests passing (294/294 unit, 138/138 cross-SDK) #11 established: a Context must never end up closed with events pending, and close must never hang.
• Needs regression coverage for a delegated/executor callback, not just the inline case.

[marcio-absmartly]

Update: this is one design problem with three entry points

Empirical results from probing f538b502 (base) and 78802a6 (PR head) with the same injected test — publisher stubbed as thenAnswer(inv -> context.closeAsync()), get(3, SECONDS):

BASE f538b502   publish-owned flush: COMPLETED_OK closed=true pending=0
BASE f538b502   close-owned flush:   DEADLOCK_TIMEOUT closed=false pending=0
HEAD 78802a6    publish-owned flush: COMPLETED_OK closed=true pending=0
HEAD 78802a6    close-owned flush:   DEADLOCK_TIMEOUT closed=false pending=0

So this issue now covers three symptoms of the same root, all deferred from #11:

1. Close-owned flush cycle (pre-existing on base). closeAsync() assigns closingFuture_ before calling flush(); the nested closeAsync() from inside the publisher sees closing_ == true and returns that same future. The publisher returns it, so the outer close waits on the flush and the flush waits on the outer close. Reproduces identically on f538b502 and 78802a6. Found by @Pedro-Revez-Silva.

2. Publish-owned flush cycle (was branch-introduced, now removed). When publishFutures_ existed, a close arriving from publisher-owned work — inline, worker thread, or executor — waited on a marker that could not settle until that close settled. Removed in 78802a6 by deleting the wait edge; regression tests publisherCanCloseContextInline, publisherCanCloseContextFromWorkerThread, publisherCanCloseContextFromExecutorCallback pin it and fail within their timeout rather than hanging.

3. Post-close stranding (accepted, base behaviour). Because close no longer awaits unrelated in-flight publishes, a publish failing after close finalized restores its batch into a closed context: getPendingCount() > 0 while publishAsync() rejects the retry via checkNotClosed(). This is what f538b502 does today. Accepted deliberately as the cost of removing symptom 2.

Why they cannot be fixed independently

Symptoms 2 and 3 are in direct tension. Close must await in-flight publishes to avoid 3, and must not await them to avoid 2. An aggregate pendingCount_ cannot separate the cases: "close waiting on an unrelated in-flight publish" and "close waiting on the publish that is waiting on this close" both present as count 1 with empty arrays. This was attempted and shown unworkable during #11.

Symptom 1 shares the root — a close-owned future handed to something that close itself is waiting on.

Direction

Per-publish ownership propagated to delegated callbacks, as suggested by @Pedro-Revez-Silva, is the only mechanism identified that distinguishes all three. Close can then await publishes it does not own, decline to await those it does, and finalize honestly.

Constraints: Java 1.6 source/bytecode floor (Android); java8.util.concurrent.CompletableFuture; anonymous inner classes only in main/java. Regression coverage must include the close-owned entry point, not only the publish-owned one — that gap is what let symptom 1 through #11's tests.