PIR: Add runner queue work distribution

[landomen]

Task/Issue URL: https://app.asana.com/1/137249556945/project/1203581873609357/task/1217191281995703?focus=true
Tech Design URL (if applicable): https://app.asana.com/1/137249556945/project/481882893211075/task/1217014195688232?focus=true
API Proposals URL(s) (if applicable): N/A

Description

Changes how we distribute work among multiple PIR runners / WebViews.

Steps to test this PR

Test on the stacked branch

UI changes

No UI changes

---

Note

High Risk
Changes core PIR parallel execution, WebView create/destroy per step, and broker-step state machine behavior; regressions could affect scan/opt-out reliability or run duration across many brokers.

Overview
PIR scan, opt-out, and email-confirmation runs no longer split jobs into fixed chunks per WebView runner. They hand all (profile, broker step) work to RealPirWorkDistributor, which either runs a shared cost-ordered queue (default, via workQueueScheduling) or the previous static equal-count chunks when the toggle is off. Expensive steps (gated clicks, fill forms, captchas) are prioritized in queue mode so slow work is not left for the last idle runner.

PirActionsRunner is now one broker step per call: execute / executeOn replace start / startOn with a single BrokerStep. Each detached run creates a WebView for that step and tears it down in finishStep (timeouts, renderer death, and sequential steps no longer share one long-lived WebView). The state engine holds a single brokerStep and finishes with CompleteExecution instead of ExecuteNextBrokerStep.

Observability adds feature.data.ext.scheduling (queue / static) on PIR pixels and matching scheduling metadata on scan wide events, aligned with the toggle at run start.

^{Reviewed by Cursor Bugbot for commit 7a73016. Bugbot is set up for automated code reviews on this repo. Configure here.}

[landomen]

• PIR: Improve webviews and action handling #9408
• PIR: Add runner queue work distribution #9407 👈 (View in Graphite)
• develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 7a73016. Configure here.}

[cursor]

Stale renderer callback fails next step

High Severity

The per-run RunContinuationHolder was replaced with a single instance-level runContinuation, while each WebView’s onRendererGone callback still routes through that shared ref. A renderer-gone message already queued on the main looper can fire after the next execute() has registered a new continuation, so a finished step’s WebView can fail the following step with PirRendererGoneException. That aborts the runner’s remaining queue work and can fail the whole PIR run. The regression is more likely now because runners intentionally pull multiple steps back-to-back, and the test that guarded this case was removed.

Additional Locations (1)

• pir/pir-impl/src/main/java/com/duckduckgo/pir/impl/common/PirWorkDistributor.kt#L95-L100

 

^{Reviewed by Cursor Bugbot for commit 7a73016. Configure here.}