Fence dedicated update-validation polls against replaced worker registrations #732

Current correction

General's PR #738 is now 83a9b55, tree 0e5a9ca3b65a0acca3f51a774b19fbfbd156a669, integrated with current main, normal published Core 2.13.1 and the completed CI repair. It captures the admitted registration fence and hashed incarnation, then checks both under the worker-row lock in every claim/retry transaction. The dedicated poll returns the existing typed stale result; obsolete requests do not consume a task.

The four fencing source/test files are byte-identical to reviewed a7c250b. The earlier source cohort passed SQLite29/321 and PostgreSQL17.11/MySQL8.0.46 each29/305; the final affected controls passed5/68 and5/66 respectively. The detailed source receipt includes the retained unfixed counterfactual: three replacement cases fail while the unchanged control passes. Current integrated PHP8.3.36/PHPUnit11.5.55 controls pass38tests532assertions and Pint; all2176installed Corefiles match normal published2.13.1. Integrated PostgreSQL17.11/MySQL8.0.46 each pass29/305 with no failures/errors/skips, retaining11 discovery deprecations in unchanged test classes. General completed the exact integration review; the new-Core/current-main unfixed counterfactual again fails the three replacement cases while its unchanged control passes. Integrated receipt. Exact head completed19successful checks/7intended skips, and PR738 merged normally at4290969ee0f99751569ac853e4e98f244696c104 (23:36:35UTC) with the exact accepted tree; remote head is verified absent. All six independent main workflows passed, the last at23:49:57UTC. The integration review is General's; no new Security verdict is claimed.

Next: publish and verify the installed fixed PHP image. The issue remains open through published acceptance. Namespace, workflow contract/fingerprint, build, attempt, lease, lock-pressure and original timing thresholds remain; native work is separately owned.

Problem

At the inspected main baseline bce669d937594aebb6b2ee45992eeb40ba63e55e, the dedicated POST /api/worker/update-validation-tasks/poll path does not fence a worker registration that changes while the request is waiting.

WorkerController::pollUpdateValidationTasks() resolves one WorkerRegistration, and WorkflowUpdateValidationTaskBroker::poll() captures that model across every repeated LongPoller::until() probe. claim() eventually calls workerMatchesTask(), but that checks WorkerPollFence::isFresh($worker) against the captured model; it does not compare the snapshot with the current registration row. A replacement registration with the same worker ID can therefore supersede the request while the old request still appears fresh in memory.

If an update-validation task wakes the old request during that window, the old request can lease it using the superseded process's routing/capability snapshot. The active replacement does not receive the task until the lease expires, so synchronous update admission can time out or be handled by the wrong worker incarnation. This is a within-namespace availability/correctness defect; no cross-tenant access or data disclosure is currently evidenced.

Workflow, activity, and query polling already carry a WorkerPollFence snapshot and compare it with current durable registration state. The dedicated update-validation poll should preserve the same replacement boundary. Closed #35 covered task-kind/version fencing for multiplexed polls, not worker-registration replacement on this dedicated path.

Acceptance

• Capture the authoritative worker-registration fence/incarnation when the dedicated validation poll is admitted.
• Before every claim, including wake and lock-pressure retry attempts, compare that fence with the current registration inside the claim transaction; do not lease when it is superseded.
• Return the existing typed stale_worker_registration poll result (or an equally explicit compatible refusal) so the obsolete request terminates without consuming the task.
• Add a counterfactual that starts a waiting dedicated poll, replaces the same worker ID with the same queue/capabilities before the next probe, makes a validation task ready, and proves the old request does not lease it while the replacement can.
• Cover changed routing/capabilities and the unchanged-current-registration control. Preserve namespace, workflow contract/fingerprint, build-ID, attempt, and lock-pressure fences.
• Qualify SQLite, PostgreSQL, and MySQL behavior and the published PHP consumer path. Do not weaken long-poll, lease, or update-validation timeout thresholds.

Original inspection evidence

• WorkflowUpdateValidationTaskBroker::poll() closes over the initially resolved model for the whole LongPoller loop.
• workerMatchesTask() calls only WorkerPollFence::isFresh() on that captured model.
• At initial inspection, no existing regression covered replacement during the dedicated validation poll; PR Fence dedicated update-validation polls to worker registrations #738 now provides it.
• Current-main source was re-fetched and inspected at the exact SHA above; no product source was changed during this review.