Skip to content

Bind sync admission policy to a stable scheduler owner #2512

Description

@branarakic

The process-global sync admission queue has no stable numeric-policy owner. resolveSyncGlobalBackpressure configures its advertised pressure capacity, while each queued payload carries a possibly different policy used by capacity checks. Interleaving callers configured with limits 2 and 10 can therefore report whichever policy was resolved last, independently of the work being admitted.

This exists on testnet-canary cc7aefa (sync/backpressure.ts: resolver configures the singleton queue; payloads carry per-call policy). Review of #2500 identified it while hardening numeric inputs. That PR removes its additional per-admission pressure reconfiguration; the underlying ownership redesign is separate from #2058's requirement to preserve valid configurations.

Choose and implement an explicit ownership contract:

  • An agent-owned controller with fixed numeric policy, live selected recovery scopes and a run boundary, including correct node-wide pressure registration; or
  • An explicitly configured process-global owner that rejects incompatible later policies, with documented multi-agent lifecycle behavior.

Preserve shared/partitioned admission, fairness/cancellation/capacity release, live Edge/RFC-64 scope changes, copied/serialized policy data, bounded metric labels and coherent pressure/status snapshots. Existing sync-operation telemetry and fetch-coalescing tests deliberately observe shared process capacity and must be migrated or preserved consciously; simply allocating a queue per call is not sufficient.

Acceptance: interleaved 2/10 policy regression; startup and same-instance restart ownership tests; shared and partitioned/live-scope regressions; no contradictory execution and reported capacities; complete backpressure, telemetry and coalescing suites pass.

Related: #2054, #2058; review #2500 (comment).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions