Skip to content

http-bridge: evicting an inflight waiter does not cancel its creator, so multiple creators race one session key #1758

Description

@Soju06

Structural follow-up split out of #1751 (which fixes #1695).

_evict_http_bridge_inflight_waiter removes the inflight future but does not cancel the creator that is still running. From that moment two (or more) creators can be in flight for the same session key, each independently selecting an account, opening an upstream socket, and claiming the same durable row.

#1751 hardened every consequence of that race it could reach:

  • every claim advances the owner epoch, so a retiring predecessor's release cannot close a successor's row;
  • a creator that has already lost its inflight slot aborts before claiming;
  • a superseded creator hands its epoch to the registered winner (same row, same account) instead of stranding it;
  • a renewal fenced by an advance from this process adopts it when the session still holds the registry slot — and refuses across a different process incarnation or a different account;
  • a creator that no longer shares the row releases it instead of preserving a row bound elsewhere.

What remains is the shape those patches cannot reach, because the premise is wrong rather than the handling:

Three-way with account divergence. An unpublished replacement claims account A; a stale creator then claims the same key on account B and settles. The row is preserved (the replacement's account is not knowable at that point), the replacement publishes holding an older epoch, its first renewal sees the row on account B, correctly refuses to adopt, and the request fails with the retryable 409. That is fail-closed and self-recovering — the orphaned account-B row is reclaimed by the abandoned purge — but a request that did not need to fail, failed, and a durable row lingers until then.

The root cause is that eviction leaves an unowned creator running. The fix is to make creation per-key single-owner: cancel the creator when its waiter is evicted, or gate creation on a registry generation so a superseded creator cannot proceed past account selection. Either is a change to the hottest bridge path and deserves its own design and review rather than another patch appended to #1751 — the same reasoning that split #1747 out of the closed #1716.

Not urgent: it needs an eviction (admission timeout) to overlap a creation and the two creators to select different accounts. Filing so the shape is recorded rather than rediscovered.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions