core: SynchronousBackendAdapter::cancelPending does not cancel the completions the adapter itself produced

[Yaraslaut]

Summary

SynchronousBackendAdapter::cancelPending (include/morph/core/backend.hpp:1039)
is a one-line forward to the wrapped backend:

/// @brief Forwards to the wrapped backend.
/// @param exc Exception delivered to every still-pending completion.
void cancelPending(const std::exception_ptr& exc) override { _inner->cancelPending(exc); }

But the two verbs this adapter exists to reshape — bindModel and
promoteModel — do not produce completions the wrapped backend knows about. They
produce a Completion whose Promise is captured by a task posted to the
adapter's own private StrandExecutor (_control, backend.hpp:1088), via
dispatch() at backend.hpp:1067-1082:

_control.post(kControlStrand, [shared, op = std::move(op)]() mutable {
    try {
        shared->resolve(op());
    } catch (...) {
        shared->reject(std::current_exception());
    }
});

Nothing in cancelPending reaches that task or that promise. The adapter
therefore violates the contract it overrides — IBackend::cancelPending
(backend.hpp:643-647) says:

Resolves every still-pending completion this backend produced with exc.
[…] After this call, any later setValue / setException on those states is a
no-op (the state is already ready), so in-flight server replies cannot resurrect
a cancelled completion.

For a bind dispatched through this adapter, none of that holds: the state is not
ready, the later resolve is not a no-op, and the completion resolves
successfully after cancellation.

Why it matters

~Bridge (bridge.hpp:419) and Bridge::switchBackend (bridge.hpp:1261) both
rely on cancelPending as their one teardown verb. A .then continuation
registered against a Bridge-owned receiver that fires after ~Bridge has
already cancelled is the use-after-free family detail::BridgeLifetime /
morph#486 exists to prevent — except that the gate protects calls into the
Bridge, not a continuation the caller attached to the returned Completion.

Severity today is limited: grep -rn SynchronousBackendAdapter finds no
production call site on master (only tests/test_backend_registration_surface.cpp,
and prose in tests/net/test_socket_backend.cpp / docs/spec/core/backend.md).
#571 proposes making this surface the default path, which is what would turn
this from latent into live.

Verification status

Reproduced. On master @ a020e69c, with clang++ 22.1.8 on Linux, a
standalone program that:

1. wraps a LocalBackend whose registerModelWithContext blocks until released,
2. calls adapter.bindModel(...) and attaches .then / .onError,
3. waits until the wrapped call is provably inside the blocking region,
4. calls adapter.cancelPending(make_exception_ptr(runtime_error{"BridgeDestroyedError"})),
5. releases the wrapped call and drains the callback executor.

Real output:

S1 SynchronousBackendAdapter::cancelPending()
  after cancelPending(): okRan=0 errRan=0
  PASS  neither continuation has run yet (the bind is still blocked in the wrapped backend)
  after the wrapped bind finished: okRan=1 errRan=0
  FINDING  the bind Completion resolved SUCCESSFULLY after cancelPending(); the adapter's own
           in-flight completions are invisible to cancelPending(), which only forwards to _inner.

okRan=1, errRan=0 is the defect: the success continuation ran after the
cancellation.

Build line (header-only; glaze is the pinned v7.4.0 FetchContent copy):

clang++ -std=c++23 -O1 -w -I include -I <glaze-v7.4.0>/include probe.cpp

What I did NOT verify:

• Whether the same hole exists for promoteModel — it goes through the identical
  dispatch() helper, so it is inferred to, not measured.
• Behaviour on the PR qt: move QtWebSocketBackend onto the structural registration surface #585 branch (origin/fix-568-qt-structural-registration @
  49bd5b8b). That branch adds bindWaitPolicy() returning
  BindWait::kCallerMustNotBlock for this adapter, which prevents the related
  awaitHandoff hang — but it does not change cancelPending, which is still the
  same one-line forward. Read, not run.
• Whether any existing test would fail if this were fixed. tests/test_backend_registration_surface.cpp
  has adapter cases but none that calls cancelPending.

What would change the verdict

• Close it if a maintainer decides the adapter is documented as not owning its
  own pending set and IBackend::cancelPending's contract is amended to say
  "completions the wrapped backend produced" — in which case the doc comment on
  IBackend::cancelPending and the adapter's @brief ("Forwards to the wrapped
  backend") both need the carve-out written down, because today the base contract
  says the opposite.
• Re-open / raise severity if core: remove IBackend's four async twins and retire the prose threading contract #571 lands and SynchronousBackendAdapter
  becomes a production path, or if a caller is found that attaches a receiver-owned
  continuation to an adapter bindModel completion.

Sketch of a fix (not implemented here)

Track the shared_ptr<Promise> handed to each _control task in a
vector<weak_ptr<...>> under the adapter's own mutex — the same snapshot-then-deliver
shape LocalBackend::cancelPending already uses (backend.hpp:1345) — and have
cancelPending reject those before (or after) forwarding to _inner. Note the
_control task must then tolerate rejecting an already-settled promise, which
CompletionState::setException's if (ready) return; already makes safe.

---

Found while writing the cancellation-entry-point table for #550 (Part 1). Row B6
of that table.

[Yaraslaut]

Triage: valid

Independently confirmed structurally, on master @ a020e69c. The reproduction is the filer's; the mechanism below is mine, and the two agree.

cancelPending is a bare one-line forward:

// include/morph/core/backend.hpp:211
void cancelPending(const std::exception_ptr& exc) override { _inner->cancelPending(exc); }

And the adapter demonstrably owns completions that _inner has never seen. It holds a private StrandExecutor:

: _inner{std::move(inner)}, _control{blockingExec} {}
static constexpr ::morph::exec::detail::ModelId kControlStrand{1};

and bindModel/promoteModel settle their own Promise on it:

auto shared = std::make_shared<Settled::Promise>(std::move(promise));
_control.post(kControlStrand, [shared, op = std::move(op)]() mutable { ... });

So the promise bindModel returns is the adapter's, living on the adapter's strand. Forwarding cancelPending to _inner cannot reach it — not as a race, but by construction. The filer's measured okRan=1 errRan=0 after cancelPending(BridgeDestroyedError) is the inevitable consequence, not a coincidence.

Why this matters more than "no production call site today"

The filer is careful to say there is no production call site on master, and that is true. It is also the reason this must not be left to be discovered later:

#571's acceptance makes this the default path. Its own text:

None of these overrides the async verbs, so all are candidates for SynchronousBackendAdapter rather than hand-editing — if any needs more than the adapter, that is worth saying in the PR, because it means the adapter's shape is wrong.

So #571 plans to route LocalBackend, SimulatedRemoteBackend and 11 test doubles through this adapter. The moment it does, a cancelPending that silently fails to cancel the adapter's own completions stops being latent — and it will be latent-looking right up until it isn't, because the adapter's forwarding is correct and only its own promises leak.

This is, in #571's own words, a case where "the adapter's shape is wrong" — surfaced before the migration rather than during it, which is the cheap ordering.

Recording the dependency: #571 is blocked by this. Not the reverse. Fixing a one-line forward is small; discovering it across 13 migrated call sites is not.

Scope

SynchronousBackendAdapter::cancelPending must cancel the promises on its own _control strand as well as forwarding to _inner. Ordering is worth deciding explicitly rather than falling out of the implementation — cancelling locally first, then forwarding, avoids a window where _inner is cancelled but the adapter's queued control task still settles successfully.

Per AGENTS.md, the test must fail if the fix is reverted: assert the bind's .then does not fire with a success value after cancelPending, i.e. assert errRan == 1 && okRan == 0. A test that only asserts "something happened" would pass today.

Worth checking while in there, and filing separately if true: whether the adapter's other forwards have the same shape — a forward that is correct for _inner's state but blind to state the adapter itself holds. setReconnectHandler at :215 is the immediate neighbour.

Context this belongs in

This is entry B6 in the cancellation-policy table on #550, and it is a concrete instance of that table's sharpest finding: every cancelPending in the tree is G2 — "a terminal onError is now posted" — not G3, "no further callback will start." Here it is not even G2; for the adapter's own completions it is G0. Anyone fixing this should read that table first, because the right fix is the one that makes this row say the same thing as the other cancelPending rows, rather than something stronger or weaker than its siblings.

What I did not verify

• I did not re-run the filer's probe; I verified the structure that makes its result necessary.
• I did not check whether any example or test double already calls cancelPending through the adapter — "no production call site" was the filer's scan, not mine.
• I did not check the ordering question above against a real race; it is raised as a design point, not a measured defect.

Labels: triage: valid, plus bug / area: core already applied.