[THardy98]

What was changed

Moves workflow sticky-polling machinery into shared types: poll admission into pollers/sticky.rs (StickyPollerShared), paired-buffer composition as StickyTaskPoller, and normal/sticky resource-based slot accounting.

Why?

Lets activity sticky polling (#1691) reuse it. Pure code movement; workflow polling remains the only consumer, so no behavior change.

Checklist

1. Closes: N/A
2. How was this tested: existing test suite.
3. Any docs updates needed? No.

[Sushisource]

High level: Do we need to do this? Could we just require that using the new affinity features means you have to use autoscaling?

[THardy98]

Yeah that could work but we probably still want the poller starvation protection, which is the bulk of what's being ported here (wait_if_needed).

[Sushisource]

Yeah that could work but we probably still want the poller starvation protection, which is the bulk of what's being ported here (wait_if_needed).

I thought the idea was, at least initially, that we'd be able to have the worker only poll on the sticky queue and we'd just transparently forward the request to the non-sticky queue on the server side.

I'm actually thinking, generally, we should move to that model for normal WFT sticky polling too. When you think about it there's really no real reason the worker needs to deal with all this sticky / not sticky logic... but that's a different story.

[THardy98]

initially, that we'd be able to have the worker only poll on the sticky queue and we'd just transparently forward the request to the non-sticky queue on the server side

Yeah, that's how it works for single-session workers: the sticky poll forwards to the normal queue until it picks up its first workflow, then it only polls sticky from then on.

For general session workers there's no forwarding at all. The worker polls the normal queue directly, and workflows it picks up get affinity through its sticky queue.

We could go sticky-only, the server needs forward on every sticky poll (or at least when sticky queue is empty), so the worker can keep picking up normal-queue work concurrently.

Polling both queues does the same thing, and supporting workers that take both session and non-session work seemed natural to me (giving our existing polling pattern).

[THardy98]

I've started a discussion for sticky-only polling in the general session worker case

[THardy98]

Based on discussion @Sushisource I think we're good to continue here