Problem
Published PHP SDK 2.0.10 exits its managed worker when a temporary upstream HTTP 503/530 response contains HTML rather than the Server JSON envelope. This is distinct from the connection-refused recovery fixed in #49.
The actual Psr18Transport::send() decodes JSON before examining HTTP status. A non-JSON error response becomes TransportException without the original status. Worker::run() then exits after the first poll with ServerException(status=0), isTransientConnectionFailure()=false, and The server returned invalid JSON: Syntax error. When connectivity returns, a process restart is required.
Independently reproduced with the published package and a PSR-18 client returning:
- HTTP200 JSON for worker registration;
- HTTP503 or HTTP530 with
Content-Type: text/html and <html>Origin unavailable</html> for polling;
- HTTP200 JSON for deregistration.
No network, credentials or infrastructure is needed. In each case the actual Worker registered normally, made exactly one poll, then threw. A malformed HTTP200 response also exits, which should remain a terminal protocol failure.
Expected
Preserve HTTP status and distinguish temporary upstream availability failures from malformed successful protocol responses. Running workers should retry the supported transient availability cases with existing bounded backoff and responsive shutdown. Do not blindly retry every malformed response, auth failure, or permanent configuration error.
Acceptance
- Focused real-transport tests for non-JSON temporary HTTP error responses during polling, registration and heartbeat, followed by recovery.
- Preserve original HTTP status through error classification; avoid dumping arbitrary response bodies or credentials in diagnostics.
- Preserve terminal behavior for malformed HTTP200, authentication/configuration errors and explicit non-retryable Server errors.
- Keep the same poll identity where the request outcome is uncertain; do not re-execute application side effects as an HTTP retry workaround.
- A published-package reverse-proxy outage/recovery check keeps the same worker process alive and completes subsequent workflow work.
- Compare Python and Rust's equivalent behavior; track only confirmed parity gaps.
Accepted product defect discovered during runtime recovery testing. This issue concerns generic SDK behavior, not provider-specific routing.
Problem
Published PHP SDK
2.0.10exits its managed worker when a temporary upstream HTTP 503/530 response contains HTML rather than the Server JSON envelope. This is distinct from the connection-refused recovery fixed in #49.The actual
Psr18Transport::send()decodes JSON before examining HTTP status. A non-JSON error response becomesTransportExceptionwithout the original status.Worker::run()then exits after the first poll withServerException(status=0),isTransientConnectionFailure()=false, andThe server returned invalid JSON: Syntax error. When connectivity returns, a process restart is required.Independently reproduced with the published package and a PSR-18 client returning:
Content-Type: text/htmland<html>Origin unavailable</html>for polling;No network, credentials or infrastructure is needed. In each case the actual Worker registered normally, made exactly one poll, then threw. A malformed HTTP200 response also exits, which should remain a terminal protocol failure.
Expected
Preserve HTTP status and distinguish temporary upstream availability failures from malformed successful protocol responses. Running workers should retry the supported transient availability cases with existing bounded backoff and responsive shutdown. Do not blindly retry every malformed response, auth failure, or permanent configuration error.
Acceptance
Accepted product defect discovered during runtime recovery testing. This issue concerns generic SDK behavior, not provider-specific routing.