Prevent poll backpressure from starving other worker task kinds

[rmcdaniel]

Problem

The managed PHP worker retries one task-kind poll indefinitely before advancing to the other task kinds. A typed HTTP 429 long_poll_capacity_exhausted response confirms that the workflow poll leased no task, but repeated responses can prevent activity/query polling entirely while worker heartbeats remain healthy.

This is a task-kind liveness defect, not a request to raise Server admission limits or result deadlines.

Reproduction

Observed with published PHP SDK 2.0.1 and 2.0.9 (2.0.9 tag commit 57e95f334639784f2cfc71bc2a40aa583356e271). Use the existing FakeTransport plus injected clock/sleeper:

1. Register a worker with one workflow and one activity, using run(5).
2. Return successful registration/heartbeats.
3. Return the actual Server HTTP429 empty-task response for every workflow-task poll: task=null, poll_status=reason=long_poll_capacity_exhausted, retryable=true, retry_after_seconds=1.
4. Other task-kind endpoints are available.
5. Advance the fake clock in the sleeper and request shutdown at60seconds.

Both published versions made 17workflow polls,11heartbeats,0activity polls and0query polls before shutdown. This exercises the installed SDK, not an edited implementation.

Worker::tick() calls pollWithRetry() sequentially. That method remains in its retry loop until the same poll succeeds, so unrelated task kinds never get a turn.

Acceptance

• Add a focused regression showing that explicit no-task wait-capacity backpressure on one kind does not starve other registered task kinds.
• Honor the advertised retry delay and retain heartbeat/shutdown responsiveness; no busy retry loop.
• Preserve poll identity, lease/fencing and ambiguous transport/backend-failure handling. An empty explicit capacity refusal is not equivalent to a lost claim acknowledgement.
• Test workflow/activity/query directions and multiple backpressured kinds.
• Inspect the analogous Python/Rust paths for the same mechanism; only claim defects demonstrated there.
• Publish the PHP patch and update the affected soak consumer to a qualified published artifact. No unchanged SDK releases merely to synchronize numbers.

Found while investigating Server #137. The focused liveness proof does not establish that this caused all six paid-soak timeouts; that run's root cause remains under investigation.

[rmcdaniel]

Release and installed-package verification are complete: #67 (comment). The affected Server capacity/soak consumer update is durable-workflow/server#161 (all PHP artifact coordinates, dependency lock and readiness checks; other SDKs unchanged). Consumer audit also found Sample App still ships a 2.0.0 lock/qualified tuple despite allowing ^2.0, so that first-user consumer needs a targeted update and qualification rather than assuming a Composer range updates installed dependencies. Waterline uses SDK 2.0.0 only as a development dependency; no managed worker runtime dependency there. Server and CLI have no SDK production dependency. Keep this issue open for consumer completion; no claim yet that the six paid-soak timeouts are fixed.

[rmcdaniel]

Server consumer follow-through is merged: server#161, 8439eefedf6031849295e4572b96853fba982374. Its public short soak completed 11/11 DW Standard Workflow v1 runs with published SDK 2.0.10, zero errors, alongside the full feature and contract checks. No Server image release is needed for this benchmark-only dependency update.

Remaining here: Sample App still locks 2.0.0 and selects that version in its qualified artifact tuple. Update those together and run the affected first-user path before closing this issue. This short Server smoke does not resolve or qualify the earlier two-hour soak timeouts.

[rmcdaniel]

Fixed and published in PHP SDK 2.0.10. PR #67 and its installed-package reproduction verify progress for activity/query polls under explicit workflow-poll capacity refusals, with retry delay, heartbeat, shutdown and ambiguous-claim handling preserved. The required soak consumer update is merged in durable-workflow/server#161 and passed qualification against the published SDK; unchanged Python/Rust pollers were inspected and did not share this sequential retry mechanism.

The additional Sample App update is tracked by durable-workflow/sample-app#90: its final tuple has passed PHP 8.4/8.5, microservice, Compose and the PHP-workflow/Python-activity/Rust-activity smoke with SDK 2.0.10 and Server 2.3.11. Prepared-image publication will be recorded there. This closes the demonstrated SDK liveness defect, not the separate unresolved six-timeout investigation in durable-workflow/server#137; paid daily soak remains paused.