Repository navigation
Published-SDK patch cohort: PHP SQLite poll refusal (backend_lock_pressure) ends the Python patch Worker #721
Description
Finding
In the published-SDK patch cohort, the published PHP 2.11.1 SQLite runtime refused a Python patch Worker's workflow-task poll with a typed 503, and the Worker exited.
Observed in run 40017239524 / job 120644918290, the execution-and-codec job of PR #708 at head 6b6757e7e2. The same shape failed #707's execution-and-codec job (job 120591054917) in signals-before-worker.
- Every PHP, embedded and Rust fixture record in the step passed first, including all operator-metrics cases.
scripts/conformance/server-parity/published-sdk-patch/python.pythen started the published Python patch-replacement Worker against the shared published-PHP SQLite runtime.- Its workflow-task poll got
503withpoll_status: backend_lock_pressureand PHP's messageWorker poll backend is temporarily locked.. The published SDK raisedServerErrorfrompoll_workflow_taskand the Worker exited. - At the same time, the PHP maintenance container logged
SQLSTATE[HY000]: General error: 5 database is lockedon a TaskRepair update: 24 repairs completed and one candidate failed. - The Worker's deregistration got one 503 and then succeeded on retry.
This is a real refusal from the reference, not an observer artifact. published-sdk-patch/observe-http.mjs deliberately never retries /poll backend_lock_pressure, even with DW_PARITY_PROXY_RETRY_LOCK_PRESSURE=1.
To decide
- Cohort scheduling. The patch cohort runs PHP's maintenance loop and a polling Worker on one SQLite file. Should the cohort keep that contention, or give them a non-contending schedule, for example by pausing maintenance during the patch window? This must not hide the refusal.
- SDK behavior.
backend_lock_pressureis a typed, retryable poll refusal. The published Python SDK ends its Worker on it instead of backing off. If the SDK should back off, that is an SDK correction (General's scope) and the cohort keeps observing the published behavior until a corrected SDK is adopted.
Acceptance
- The observer never retries
/polllock pressure invisibly. - Either the cohort shows no contention by construction, with evidence, or the SDK correction is linked and the cohort records the published behavior as a known reference outcome.
- Native runs are unaffected. This happens only on the published PHP reference.
Owner: Rust Server (cohort harness). SDK question routed to General.
Activity
rmcdaniel commentedon Oct 23, 2026
Accepted SDK correction: Python #218.
Current published Python 2.11.0 source confirms the specific gap in Worker.run_until(): its bounded helper rethrows workflow-poll failures and has no activity-poll recovery handler. The normal long-running Worker.run() loops already back off under #189. The helper should recover from a complete, correctly bound transient refusal inside its original remaining deadline, while preserving persistent timeout, stop, fatal/protocol errors and claim identity. Direct Client transport policy remains a separate layer.
General will reproduce the normally installed helper counterfactual, implement the focused correction and qualify a compatible patch before any adoption claim. Rust Server retains this cohort and exact frozen identities. The original failure remains failed, with no observer retry or budget change. Please preserve the actual installed SDK version/source in this finding; the source profile alone does not prove the effective failed-run identity.
rmcdaniel commentedon Oct 24, 2026
Cohort scheduling (decision 1) is in #722: the SQLite patch-cohort PHP record runs with the maintenance loop stopped. The loop state is recorded and asserted (
running,exited,running), and the loop restarts after the record or on failure. The observer still never retries poll lock pressure. The SDK behavior (decision 2) stays with sdk-python#218. The #707signals-before-workerinstance was in the main SQLite PHP record, outside this cohort, and stays open here.Server parity: arm the maintenance restore before the stop and keep i…
Server parity: name the maintenance container from the job identity (#…
rmcdaniel commentedon Oct 24, 2026
The SDK correction is published: durable-workflow (Python) 2.11.1 (sdk-python#218, comment 6379992991). Next: a reviewed fixture change that moves the published-sdk-patch cohort's frozen Python identity from 2.11.0 to 2.11.1, with installed identity evidence. The original 2.11.0 failure stays recorded as failed.
Start SQLite's published PHP maintenance loop for both corpus parts
rmcdaniel commentedon Nov 4, 2026
Server open-item pass, 2026-11-04.
Owner: Server for cohort identity/scheduling; SDK Python owns the run_until transient-refusal correction. #722 already isolates the SQLite patch window with maintenance restoration, and Python2.11.1/#218 is published. The remaining action is the exact frozen-profile identity move/installed receipt, not another SDK fix or an observer retry.
sdk-python: return the normally installed correction and current profile-adoption receipt, including unchanged remaining deadline and fatal/persistent refusals. Server will reconcile the maintained runner and any main-corpus signals-before-worker instance separately. General owns any frozen-actor scope decision. The original2.11.0 failure stays failed; poll lock pressure is never hidden.
rmcdaniel commentedon Nov 4, 2026
Python's installed correction is complete in SDK #218 final receipt: normally published 2.11.1, source
351192443943d645f84b541b4e45f2b002e81193, wheel SHA-2561e7f0210ef30ae33e2224f6857386a43e7793b725a298a0974b2bd6e53c0318f, protected publisher 40061568529. Five fresh originals against immutable PHP Server 2.11.1 indexbf8bed13f5f809ee3425233180a581353eac4683adbee5c4ecbf63bb18bbd102pass: healthy default and workflow/activity poll pressure in default/named namespaces. The real refusal controls preserve the original 25-second helper, one-second poll and 30-second run/execution budgets, plus separate ten-second shutdown. The source also retains fatal/foreign, persistent-refusal-to-original-deadline and stop controls; those are distinct from the five installed live originals.The unchanged published 2.11.0 counterfactual and historical failures remain failures. The SDK final receipt explicitly leaves frozen-profile/cohort scheduling and adoption to Server/General; I have no separate SDK-owned frozen-profile adoption receipt to transfer. Next action: Server reconcile its maintained runner/profile identity against this accepted artifact, and General decide any frozen-actor scope move. No new run or SDK fix is started by this readback.
rmcdaniel commentedon Nov 11, 2026
Closing: fixed in sdk-python 2.11.1 (sdk-python#218); parity is green.