[rmcdaniel]

Worker polls can lose a response after the Server has claimed a task. The PHP client now negotiates Server offer/accept delivery, accepts one selected packet before exposing a task, and retains that exact request across uncertain responses and Client clones. Registration replacement fences old packets; explicit worker stops remain terminal. Servers without the capability retain the existing poll behavior.

Refs durable-workflow/server#526 and supporting Server draft durable-workflow/server#758. This PR remains draft while latest-head checks and the remaining delivery qualification run. It does not establish fixed published Server-image acceptance.

Validation: latest head 13700088131c74a00fb3b656eb5d2c1c8c543d5a passed all 41 checks with one intended skip. Hosted PHP 8.3: 2,858 tests / 14,911 assertions, 56 existing fixture-dependent skips; PHP 8.1/8.2/8.4 also passed. Local focused qualification: 106 tests / 488 assertions and PHPStan pass. Sonar has zero unresolved PR findings; both earlier maintainability findings were corrected without waiving rules.

Actual PHP SDK HTTP tests against two candidate PHP Servers with MySQL/Redis passed all three four-second idle polls through a three-second nginx proxy. Lost positive replies replayed the original workflow/activity/query claim after offer expiry and a normal heartbeat on the other replica, with attempt 1 and identical acceptance requests. An abandoned offer left a peer immediately able to claim. The query public consumer used a direct Server control route and received its completed result; worker polls stayed behind the short proxy. All disposable services/network/volumes were removed. HTTP checks used source 086b383; the later terminal-stop and classification changes are covered by the focused suite.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rmcdaniel]

Exact-head review of 13700088131c74a00fb3b656eb5d2c1c8c543d5a found a separate client-side overlap in the draft delivery contract.

TaskDelivery::poll() makes concurrent callers for one logical poll share the first retained packet, but it does not single-flight delivery of the accepted result. A synthetic PHP 8.3 Fiber transport reproduced this interleaving:

1. Two calls on the same Client start the same worker/queue/kind/poll_request_id and both pause while requesting an offer.
2. The second offer resumes first and becomes the retained packet.
3. Both calls send acceptance for that same retained packet.
4. Replayed positive replies return the same executable task to both callers.

Observed result: both poll calls returned the byte-identical claimed task. The test used only an injected synthetic Transport and no live service. This is a draft SDK correctness boundary, not evidence of current released exploitation and not the Server query-cache race already recorded on server#758.

The client needs one execution consumer per logical-poll key even when retries overlap. Please add a deterministic same-Client/clone concurrency regression proving that overlapping calls cannot both receive execution authority; one call may own the result while the other waits or receives a non-executable retry outcome. Preserve the existing immutable-packet retry behavior for a genuinely lost response.