Skip to content

Simplify client pool waiter state transitions #535

Description

@leynos

Problem

The 2026-06-05 code-base audit found that src/client/pool/scheduler.rs still mixes waiter selection, restart logic, and state mutation across several helper paths. In particular, the scheduler paths around waiter acquisition and restart handling remain harder to reason about than the rest of the planned pool refactor.

Suggested fix

Extract explicit state-transition helpers for the pool waiter flow, for example:

  • acquire the next waiter for a handle;
  • decide whether the scheduler should restart when waiters remain;
  • take or stop the next waiter without embedding policy in the caller.

The aim is to make the scheduler read as state transitions rather than nested control flow, while preserving existing public pool behaviour.

Context

Related draft plan: #534

This is intentionally tracked outside the current ExecPlan because that plan already covers lock recovery, builder-parts construction, and lease dispatch visibility.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions