Repository navigation
worker-sdk-persistent-pressure: published PHP's SDK shutdown missed the 8-10 s window on MySQL 8.0 #728
Closed as not planned
Description
Goal
worker-sdk-persistent-pressure passes reliably on every backend. Its "one real SDK budget expires while pressure stays held" check measures the published PHP SDK's shutdown while an independent database write lock is held, and requires 8 to 10 seconds.
Observed
- Train Rust Server train: MySQL statement closes (#714), update validation, policy-map JSON, worker history presentation #723 at
1fd9e549a, run 40069368271, jobmysql-execution (mysql-8.0), step "Compare SDK temporary database pressure with declared fault limits": the published PHP target failed that check. The native and embedded records never ran, because the PHP record fails the step first. - The same cell passed on
main's three latest runs (40057998770, 40002197719, 39961767541). The train does not change this profile, its contract, the published PHP image or the SDK. - The measured shutdown time was not printed, so it is unknown whether shutdown took under 8 s or over 10 s.
Done so far
ef5a6be70 (in #723) makes the assertion print the measured time and backend. The window is unchanged.
Next
If it recurs, the printed time shows whether the PHP reference ran past its budget under CI load or the window is too tight for the SDK's declared budget. A change to the window needs a recorded contract decision, not an edited expectation.
Activity
rmcdaniel commentedon Nov 4, 2026
Server open-item pass, 2026-11-04.
Owner: Server for the unchanged pressure/shutdown assertion; SDK PHP owns shutdown semantics, General owns any contract decision. The measured-time diagnostic is already committed. The original failure did not print a value, so it cannot be attributed to an overrun versus underrun after the fact.
Next: inspect a genuinely new occurrence’s retained measured time/backend/SDK identity, or prepare a source-only below/inside/above-window countercontrol. Do not widen8–10s without an explicit declared-budget decision. SDK PHP: confirm the current shutdown-budget contract and any known source receipt; no fresh workload or substitute SDK tuple is requested.
rmcdaniel commentedon Nov 4, 2026
PHP's declared bound is one ten-second deregistration budget covering connection setup, requests and backoff, not a promise to take at least eight seconds or a bound on an arbitrary in-flight synchronous activity.
requestShutdown()stops future polling;run()settles its active call and then cleans up. With validated worker_deregistration_fencing and bounded transport it retries the same registration token. A remaining cooperative-cancellation deadline can shorten the budget. A retry delay that would exhaust it is refused before sleeping, so terminal failure may legitimately precede ten seconds. Older/unbounded transports have the documented single-attempt path.Source is SDK #110, merge 4dd3bdc49ddb18b216348e0da29f398e305586b3. Current accepted behavior is in Worker::deregisterWithRetry, budget and real-request-time controls, and the graceful-shutdown contract.
Existing installed proof is Server #358/6104335440: published SDK 2.2.7 (7c40c775) against immutable PHP Server 2.5.17 (e260111), thirteen actual HTTP cases, with persistent refusal at 9.20 seconds retaining active registration and original authority. That exact historical tuple is not new proof for a later native/SDK tuple. It also covers lost reply after commit and source/budget failures; the original unmeasured failure cannot be retrospectively assigned an overrun or underrun.
Server owns its measured-time/countercontrol fix and any genuinely new exact-tuple acceptance; General owns an intended assertion/contract change. PHP has not widened a budget or run another workload. The current SDK does not declare an eight-second lower bound.
rmcdaniel commentedon Nov 11, 2026
Closing: no recurrence since measured-time logging was added. Reopen with the printed time if it happens again.