Three audit findings from the post-merge review:

- **Multi-`InputId` could call `start_task` twice with the same `task_id`.**
  `start_task` rewinds prior claims back into the global budget, so a
  second call would corrupt the count. With `max_concurrency=1` the
  streaming-sink machinery still creates a fresh state per `InputId`,
  not one state globally. The previous `started: bool` on `State` only
  guarded per-state, not per-sink. Move `started` to a shared
  `Arc<tokio::sync::OnceCell<()>>` on the sink so the actor is told
  exactly once per task, regardless of how many states the runtime
  creates.

- **`task_claims` HashMap on the actor grew unbounded.** Every task
  past the limit accumulated a `(0, 0)` entry that was never evicted —
  O(partitions) memory tied to one query. Drop the entry when its
  accumulated claim totals to `(0, 0)`; rewinding `(0, 0)` on retry is
  a no-op, so this is information-preserving.

- **Silent `"unknown"` fallback when `task_id` is missing from
  `BuilderContext.context`.** Would collapse every malformed task's
  claims under one key and break retry-rewind without surfacing
  anything. The invariant always holds in practice (the builder
  stamps it), so a missing entry is a real bug — panic instead of
  fall back.

Full `DAFT_RUNNER=ray` limit suite still passes (210 tests).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Per simplify review:
- `actor_ready_timeout` duplicated config already reachable via
  `self.config.execution_config.actor_udf_ready_timeout` — read it
  directly at the call site.
- `schema` was captured into the `append_distributed_limit_to_builder`
  closure only to be ignored with `let _ = schema;`. Drop the capture.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Two new CI failures from the prior cleanup:
- check-unused-cargo-deps: `daft-stats` was only used by the
  `estimated_num_rows` tests that just got deleted.
- style (no-python feature): `DistributedLimitSink` is gated on
  `feature = "python"`, but the import in `pipeline.rs` was
  unconditional, breaking the non-python build. Move the `use` into
  the gated match arm.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Adds direct unit-tests for the distributed-Limit state machine
(_LimitCounterImpl): claim/offset arithmetic, start_task rewind on
retry (refund of skip + take, per-task isolation, double-call
idempotence), and the boundary-task bookkeeping invariant.

Writing the boundary-task test surfaced a real bug: start_task
unconditionally inserted (0, 0), but claim()'s early-return path (taken
when the global limit was already hit) skipped the cleanup branch, so
every post-limit task left a (0, 0) entry behind. task_claims grew
O(total tasks scheduled) instead of O(boundary tasks) as the comment
claimed. Fix: register entries lazily in claim() only when budget is
actually consumed, and pop in start_task on rewind.

Also splits LimitCounterActor into a pure-Python _LimitCounterImpl
class plus a ray.remote()(...)-wrapped Ray actor handle so the
state-machine logic is testable without standing up a Ray cluster.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The distributed Limit operator claims budget in whichever worker order
the actor sees first, not strict partition-index order, so
`df.limit(N)` no longer matches `iceberg_pandas[:N]` row-for-row. The
`_on_number` variant already sorts-before-limit for the same reason
(comment dating from a prior scheduling change); apply the same fix to
the `date`, `timestamp`, and `letter` variants.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

- eprintln! -> tracing::warn! in LimitActor::teardown.
- debug_assert! the i64 claim values are non-negative before casting
  to usize.
- Replace the no-op `try: import ray; except ImportError: raise` with
  a real user-facing message (wrapping is still required to satisfy
  ruff TID253).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Three small cleanups surfaced by a simplification-focused re-review:

- Drop `LimitCounterHandle.is_done` — defined but never called from
  Rust or tests. `_LimitCounterImpl.is_done` stays because the unit
  tests use it.
- Drop `DistributedLimitSinkState`. The struct carried two Arc clones
  that were already on the sink itself, so the state was pure
  boilerplate. Use `type State = ()` and clone from `&self` in
  `execute()` directly. Removes ~10 lines and the `make_state`
  ceremony.
- Rewrite `start_limit_counter_actor`'s readiness wait in terms of
  `asyncio.wait_for` — the manual `asyncio.wait(...)` + non-empty
  check + `asyncio.gather` was reimplementing the same primitive.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The old comment said "sharing one pipeline lets the streaming sink hit
Finished once and kill the pipeline for everyone after it" — confusing
phrasing, and it omitted the more fundamental reason: the
DistributedLimitSink also bakes in the task's task_id at construction,
which the actor uses as the bookkeeping key for retries. Two tasks
sharing one cached sink would also share one task_id at the actor.

Also rename `execution_loop_fused` -> `limit_execution_loop` to match
the surrounding node-name convention; nothing was being "fused" anyway.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…erprint

`DistributedLimitSink` previously baked the SwordfishTask's task_id in
at sink construction so the actor could attribute per-task claims for
retry-rewind. That forced `LimitNode` to stamp a unique fingerprint per
task to defeat the worker's pipeline cache — every task built its own
pipeline.

Use the framework's own per-input identity instead: extend the
`StreamingSink::make_state` signature with `input_id: InputId`, which
matches the SwordfishTask's task_id in flotilla mode (asserted at
`run.rs:447-451`). The distributed-limit state derives
`task_id = input_id.to_string()` and owns its own `OnceCell<()>` for
the `start_task` guard, so:

- The sink itself is task-agnostic — no `task_id` field, no shared
  `Arc<OnceCell>`.
- Workers cache one compiled pipeline per `plan_fingerprint`. The
  seq-based fingerprint stamping in `LimitNode` is gone.
- Each new SwordfishTask landing on a worker gets a fresh state with
  its own task_id and OnceCell; retry-rewind correctness is preserved.

Other `StreamingSink` impls (Limit, Sample, AsyncUdf, VLLM,
MonotonicallyIncreasingId) just accept the new `_input_id` parameter
and ignore it.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The `make_state` plumbing is documented at the sink itself; restating
it at the call site is noise.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

`LimitNode` previously kept forwarding builders even after the actor's
budget was exhausted; each downstream worker would then spawn, do its
`start_task`+`claim` round trip, get `done=True`, and tear down — small
per-task waste, but multiplied across many partitions.

Restructure `limit_execution_loop` as a `tokio::select!` between the
upstream task stream and the running-tasks `JoinSet`. Whenever a
forwarded task completes (notify_token fires), ask the actor
`is_done()`. If true, stop forwarding — `result_tx` is dropped, the
input stream closes for downstream, and any in-flight tasks
short-circuit naturally on their next `claim`.

No cancel-token plumbing needed: the existing flow is already cheap
enough once the actor returns `done=True`. The win is purely "don't
hand out more builders to workers that would do nothing."

Also inlines the `wrap_with_distributed_limit` helper and drops the
result_tx scoping comment.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

`SchedulerSender` is unbounded, so by the time the LimitNode forwards a
builder it's already been submitted into the scheduler queue and the
`SubmittedTask` is held by `materialize::task_materializer`. Dropping
`result_tx` only stops *future* forwards — the queued ones still get
dispatched.

Wire a shared cancel-token through:
- Add `SwordfishTaskBuilder::with_cancel_token` (`Option<CancellationToken>`,
  consumed at `build()` to bind to the resulting `SubmittedTask`).
- `LimitNode` owns a `parent_cancel`; every forwarded builder gets a
  child token. When the actor reports `is_done`, drop `result_tx` and
  cancel the parent, which propagates to every in-flight + queued
  `SubmittedTask` via the existing `TaskResultAwaiter` cancel path.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Once `parent_cancel.cancel()` fires, every in-flight `SubmittedTask` gets
`TaskStatus::Cancelled` via `TaskResultAwaiter`'s biased select on the
cancel branch (`task.rs:561-569`), and `materialize::task_materializer`
treats Cancelled as a normal termination — not a query error. A worker
that races with `ray.kill(actor)` on a `claim` RPC just surfaces the
RPC error along the same cancel path; nothing leaks to the query.

The drain loop was a defensive wait for scheduler-side resolution, but
it only weakly approximates "workers stopped calling the actor" anyway
(Ray's cancel is async). Removing it for simplicity; ray-runner
limit/offset tests (200) still pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

`RemoteFlotillaRunner` is pinned to the head node (`flotilla.py:592-599`),
and every `claim`/`done` RPC against the LimitCounterActor originates
inside the LimitNode running in that runner. Defaulting the actor's
placement to "DEFAULT" let Ray put it anywhere, paying a cross-node hop
per RPC. Pin to the runner's current node via
`NodeAffinitySchedulingStrategy(node_id=current, soft=False)` so the
actor lives on the same node and every RPC stays local.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Both `DefaultScheduler` and `LinearScheduler` previously dispatched
cancelled tasks all the way to a worker before the cancel propagated
back through `TaskResultAwaiter`. Filter at both entry points:

- `enqueue_tasks` drops already-cancelled tasks before they hit the
  pending queue.
- `schedule_tasks` skips cancelled entries it pops from the queue
  (drops `result_tx`, which signals the SubmittedTask's `Err` path —
  treated as a normal cancellation by `task_materializer`).
- `pending_tasks_in_priority_order` filters cancelled tasks so the
  autoscaling demand doesn't include resources we'll never use.

Also trim the `DistributedLimitSinkState` doc-comments and drop the
redundant doc on `SwordfishTaskBuilder::with_cancel_token`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The actor's bookkeeping key is sourced from the streaming-sink
framework's `InputId` (cast to a string), not from a SwordfishTask-side
`task_id` constructed at sink-build time. The two happen to coincide in
flotilla mode (asserted at `run.rs:447-451`), but calling the parameter
`task_id` everywhere obscures where the value actually comes from.
Rename to `input_id` in:

- `_LimitCounterImpl.{start_task, claim}` and `LimitCounterHandle`.
- `_LimitCounterImpl.task_claims` -> `input_claims`.
- `DistributedLimitSinkState.task_id` -> `input_id`.
- `tests/test_distributed_limit_actor.py`.

Public Python method names (`start_task`, `claim`) are unchanged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

clippy::unwrap-or-default fires on
`self.cancel_token.unwrap_or_else(CancellationToken::new)`. `CancellationToken`
already implements `Default` as a fresh independent token; switch to
`unwrap_or_default()`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

When a downstream node batches its input — e.g. `IntoPartitionsNode`
used by `df.into_batches(...)` — forwarded builders are buffered and
only submitted after the LimitNode's `result_tx` closes. Cancelling
`parent_cancel` on the natural-exhaustion exit path would then drop
those just-submitted builders via the scheduler's is_cancelled filter,
silently returning zero rows from `df.limit(N).into_batches(M)` and
similar chains.

Only cancel when the loop broke because the actor reported `is_done`.
Natural exhaustion of the input stream means everything was already
forwarded for legitimate processing; no cancellation needed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The `is_cancelled` filter at the scheduler (added so `LimitNode` can drop
pending tasks once the limit is satisfied) was silently dropping cancelled
tasks. This broke two invariants:

- `dropping_result_stream_still_finalizes_operators` lifecycle test: every
  `OperatorStart` is supposed to be paired with `OperatorEnd`, but tasks
  cancelled at the scheduler emitted neither a `TaskStatus::Cancelled` nor
  a `TaskEvent::Cancelled`, so the lifecycle gate never closed.
- UI/observability: nodes whose tasks were all filtered before dispatch
  would show as perpetually "running."

Change `Scheduler::{enqueue_tasks, schedule_tasks}` to return the
cancelled-pending-tasks they dropped. `SchedulerLoop` emits
`TaskEvent::Cancelled` for each and then drops them (closing their
`result_tx`, which unblocks awaiters with `Ok(None)`).

`test_scheduler_actor_cancelled_task` previously assumed a cancelled task
always reached a worker so its `cancel_callback` would fire the notifier.
With the scheduler-side filter that's no longer guaranteed — accept either
path (callback fired *or* notifier dropped) as valid cancellation.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

- Move all cancel-token filtering to `schedule_tasks` — `enqueue_tasks`
  keeps its old signature and accepts everything. Tasks that were already
  cancelled when enqueued sit briefly in the queue, then get filtered (and
  Cancelled events emitted) on the next schedule cycle.
- Rename `wait_for_contributors` → `await_limit_completion`.
- Trim verbose comments.

- Drop verbose docstrings in `_LimitCounterImpl` / `LimitCounterHandle` /
  `start_limit_counter_actor`; the method bodies and types are clear on
  their own.
- Replace the `loop { if done { break; }; select! { ... } }` pattern in
  `LimitNode::limit_execution_loop` with a `while` whose match returns
  "still pending."