Let a new filter supersede expensive work already in progress

Project context

A fictional repair coordinator opens a week containing 2,000 jobs. The initial page loads, but filtering and selecting a job can freeze the interface. Build a synthetic scheduling screen with keyboard operation before measuring changes.

Setup prerequisites

• Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses.
• Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison.

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

• PWEB-101 · Record the schedule workflow that freezes after filtering
• PWEB-103 · Measure long tasks caused by filtering rather than counting renders alone
• PWEB-105 · Render only the visible schedule rows without losing keyboard position

Acceptance criteria

• Choose a bounded scheduling or worker strategy and explain why it fits the measured bottleneck.
• Publish results only for the current dataset and query revision; discard superseded work safely.
• Preserve responsive keyboard input and a clear pending state without moving focus or showing stale result counts.

Implementation constraints

• If using a worker, include transfer/serialization cost in the comparison and terminate it when the screen unmounts.

Verification to include

• Complete an older query after a newer query and verify only current results appear.
• Type and clear rapidly while replacing the dataset, then inspect responsiveness, final IDs and worker or task cleanup.
• Repeat baseline and selected-strategy runs three times under the same recorded browser workload; compare input-latency distributions and long-task counts, including worker transfer and serialization overhead when applicable.

Deliverables

• Scheduling decision, implementation and out-of-order completion tests

Rollout and recovery

Canary the alternate filter path locally; reverting cancels its work and restores synchronous filtering with the same query state.

Value of the work

For the engineer: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility.

For the team: Produce a bounded performance investigation and regression workflow for dense operational interfaces.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.