Pool: a new get can take a released item ahead of queued waiters #9875

What version of Effect is running?

4.0.6 (also present on main: packages/effect/src/Pool.ts, wakeWaiters)

What steps can reproduce the bug?

When a pool item is released, wakeWaiters defers the wake-up with fiber.currentDispatcher.scheduleTask(..., 0), but the item is already marked available. A Pool.get that runs before that scheduled task (for example, the releasing fiber borrowing again right away) takes the item ahead of fibers that were already queued.

import { Effect, Exit, Fiber, Pool, Scope } from "effect"

const program = Effect.scoped(
  Effect.gen(function* () {
    const pool = yield* Pool.make({ acquire: Effect.succeed("connection"), size: 1 })
    const holder = yield* Scope.make()
    yield* Pool.get(pool).pipe(Scope.provide(holder))

    const order: string[] = []
    const borrow = (name: string) =>
      Effect.scoped(Effect.gen(function* () {
        yield* Pool.get(pool)
        order.push(name)
      }))

    const first = yield* Effect.forkChild(borrow("first"), { startImmediately: true })
    const second = yield* Effect.forkChild(borrow("second"), { startImmediately: true })

    yield* Scope.close(holder, Exit.void) // release the only item
    yield* borrow("newcomer")              // borrow again right away

    yield* Fiber.join(first)
    yield* Fiber.join(second)
    return order
  })
)

Effect.runPromise(program).then(console.log)

What is the expected behavior?

["first", "second", "newcomer"]: a released item goes to the oldest queued waiter before any new get can take it.

What do you see instead?

["newcomer", "first", "second"].

Additional information

We hit this with an @effect/sql-pg connection pool under load. Busy fibers that release and immediately re-borrow keep getting connections, while queries already waiting in the queue starve until they hit their acquire timeout. Older work times out even though the pool keeps serving newer work.

A possible fix is to hand the released item to the oldest waiter synchronously during release (reserving it for that waiter), instead of publishing it as available and waking waiters on a later tick. The handoff also has to return the reservation if the waiter is interrupted. We have a local patch along these lines with tests for FIFO order across get/use, interruption during handoff, concurrency > 1, and invalidation, and can share it if that helps.