Skip to content

A refused user dispatch still waits the full dispatchTimeout — bound it on the violation #20

Description

@styk-tv

Split out of #19, explicitly out of v1.5.9 scope.

After CK.activate returns, an arbitrary user dispatch (e.g. k.query) on a refused subject still waits the full dispatchTimeout before its promise rejects with "timed out" — measured ~60s on pgCK.MCP's config, while the broker refused it instantly. The refusal is emitted on the error channel at once (#19), but the returned promise is not rejected early.

Why not fixed in #19: the client-side violation carries no subject (d-26, measured), so it cannot be correlated to the specific pending dispatch to reject it. activate's own calls are bounded by discoveryTimeout (#19); an arbitrary user dispatch has no such bound.

Candidate fixes, none shipped:

  • Clean: a subject on the wire (or the reply-envelope naming what was refused) → reject the exact pending dispatch. Needs substrate/transport support (RULE-11 / reply-envelope).
  • Heuristic (measure first): if exactly one dispatch is pending when a subject-less violation arrives, reject it. Sound post-activate (sequential), but a window exists where a concurrent granted dispatch could be wrongly rejected — not shipping on a guess.

From a consumer's seat this is "connected, subscribe-only, then a full dispatchTimeout of silence per refused read" — a refusal presenting as a hang, one layer below activate. Blocked on the reply-envelope / a subject on the violation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    identityIdentity, admission, attribution

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions