Preserve HTTP failures before checking control-plane response envelopes

[rmcdaniel]

Operator problem

The published-artifact diagnosis drill in durable-workflow/.github#143 exhausted a bounded MySQL system tablespace. A workflow start returned HTTP 500. Published CLI 2.1.2 instead reported invalid control-plane response version for [/workflows]; expected [2], got [missing] and exit code 1. This points the investigator toward a protocol mismatch rather than the failed server operation.

The current ServerClient::decode() handles 401/403 before normalizing protocol envelopes, but other HTTP errors reach normalizePayload() before their status is classified. A generic Laravel JSON error without the success envelope therefore masks the actual HTTP error.

Acceptance

• Preserve HTTP status and useful error details for non-success responses without a Server success envelope, including JSON, HTML and empty proxy responses.
• Keep normal success-response protocol checks strict. Preserve existing typed authentication, validation, rejection, compatibility and retryable-backend behavior.
• Include regressions for the observed workflow start failure and the error response shapes that exercise this ordering.
• Publish the qualified patch and repeat the actual storage-pressure operation with the published CLI.

Frozen reproduction: Server 2.4.30, CLI 2.1.2, Waterline 2.0.8, MySQL 8.4.5. The isolated database uses innodb_file_per_table=OFF and ibdata1:32M:autoextend:max:64M. A bounded filler table reaches the limit, then a 96-KiB synthetic workflow input makes the workflow_runs insert fail with MySQL error 1114. Restoring a bounded 128-MiB limit recovers previously acknowledged work. No customer environment or paid test host is involved. Server's storage-specific explanation is a separate finding from the CLI's response-ordering defect.

[rmcdaniel]

Implemented and merged in #36 at 1012e1c. Required PHP 8.2–8.5 tests, PHAR build and reproducibility pass. Live control/worker smoke against published Server 2.4.30 passes 76 assertions using a published-SDK Avro completion payload. Next: finish the repository-required release evidence for CLI 2.1.3, publish all distribution assets, and repeat the original bounded MySQL storage-pressure start with that exact published CLI. The issue remains open until that repeat verifies status 500, useful error details and the server exit code instead of a missing-envelope message.

[rmcdaniel]

Release review found a documentation mismatch that needs correction before CLI 2.1.3:

docs/conformance.md requires a full platform harness result for every CLI tag, including every unrelated runtime scenario. It names suite 27 and a public harness process that has no executable reference implementation in the CLI. The current public suite is 47. Command and schema fixture tests do run in normal CI, but they are not a full platform runtime result.

The organization guide requires release experiments selected for the changed behavior, with normal CI and exact published-artifact verification. Its release follow-through rule explicitly scales coverage to risk. The public suite separately gates releases publishing a platform compatibility claim. I will reconcile the CLI document with those authorities, preserving the full catalog gate for platform claims and documenting concrete maintenance-release checks. No partial result will be relabeled full or provisional.

For this HTTP-error maintenance patch, required qualification is PHP 8.2–8.5 command/schema tests, PHAR build and reproducibility, live control/worker smoke, all supported distribution assets, and the original bounded MySQL start failure with the exact published CLI. Successful response validation and typed errors remain covered by the full normal command suite. Publication is followed by the actual storage repeat before closing this issue.

[rmcdaniel]

CLI 2.1.3 release qualification:

• The HTTP failure fix is merged in Preserve HTTP errors when response envelopes are unavailable #36. The release-document correction is merged in Clarify maintenance release qualification and platform claims #37 at bc72ab546780a065d166b165cdea2853f547130b. Its remote head is deleted and verified absent.
• Every normal check passes on the exact release commit, including PHP 8.2–8.5 command/schema tests, PHAR smoke and reproducibility. Main Build 36711528685 is successful.
• Focused HTTP/client/worker regression coverage passed 72 tests and 512 assertions. Live control/worker smoke against published Server 2.4.30 passed 76 assertions, including a completion payload encoded with published PHP SDK 2.1.6. The release commit changes only the conformance document after that runtime qualification.
• This is scoped HTTP-error maintenance qualification. No full platform harness result or new aggregate compatibility claim is made.

Publish 2.1.3 through the protected release workflow, require the portable PHAR and all four native platforms plus installers and checksums, then verify the original bounded MySQL start failure using the exact published CLI with Server 2.4.30. Also use the new CLI in Server #284's published-image recovery drill. #35 remains open until the original failure repeat confirms HTTP status 500 and the proper server exit code instead of a missing-envelope diagnostic.

[rmcdaniel]

Published fix and original failure repeat verified

CLI 2.1.3 is published from immutable source bc72ab546780a065d166b165cdea2853f547130b. Release verification passes, including the PHAR, all four native platforms, checksums, pinned/default installers and upgrade checks. The website's canonical stable CLI authority now resolves to 2.1.3 through durable-workflow/durable-workflow.github.io#148.

Repeated the original bounded MySQL failure with published Server 2.4.30 and the downloaded CLI 2.1.3 PHAR. The failed workflow start reports HTTP 500, Server Error, exit code 6. It no longer substitutes a missing response-envelope error. The failed start leaves zero workflow instances, and the earlier three acknowledged baseline runs remain completed once.

Also verified the published CLI against Server 2.4.31's new capacity diagnostic. A blocked 512-KiB start reports 503, database_storage_exhausted, exit code 6, preserving the resource, retryability and remediation fields under server_response. That failed start leaves no instance. Starts acknowledged before capacity recovery complete once after the original storage is restored.

The PHAR SHA-256 is 058ab6d41e78f6d627664d23d69e91762590bff8d1b89918ebaafc7bc25b9727. Retained synthetic evidence and procedure includes both Server-version repeats, CLI responses and exit codes, transaction checks and artifact identities. Checksum was verified after downloading the published archive.

This completes #35's acceptance criteria. Sample App's pinned CLI consumer update is the next downstream action and is recorded on Server #284. Unchanged SDKs require no release for this HTTP-client ordering fix. The broader timed operator drill remains open in durable-workflow/.github#143.