Repository navigation
Shared corpus: published PHP namespace-delete-payloads intermittently answers 207 (pending deletion) on SQLite #1018
Description
Observed
In merge-group run 41774098014 (job execution-and-codec (corpus), SQLite), the published PHP 2.11.8 reference failed the namespace-delete-payloads fixture at step "peer deleted". It answered 207 with external_payload_cleanup.pending: 1, where the reviewed expectation is 200 with nothing pending. Evidence: php.failure-excerpt.txt in the run's shared-server-fixtures-corpus artifact. Native passed the same fixture in the same job.
- The tree was
d92e078d(server#1011 at7d75aa79). The same tree passed every check, this fixture included, on the PR run 41764451120. Keep every digit of JSON doubles: enable serde_json float_roundtrip (#1010) #1011 doesn't touch namespace deletion or external payloads. - The PHP container's maintenance loop shares that SQLite database and was logging
database is lockedin the same job's container tails.
Likely cause
Published PHP settles a namespace's external payload deletions after the delete commits, and answers 207 while one is left pending. Under SQLite lock pressure from the one-second maintenance loop, that settlement can lose the race, so the reference intermittently answers 207 instead of 200. Native mirrors that 207 contract (namespace_cleanup.rs); it just didn't hit the race here.
Needed
Keep the shared corpus deterministic against the frozen PHP reference. Options:
- retry the delete's settlement observation, as other probes retry lock-pressure refusals (
LockPressurePollRetries); - read back the pending deletion until it settles, then assert the final state;
- or record the 207-then-settled shape as a reviewed alternative for the PHP target on SQLite only.
The fixture must still fail if a deletion stays pending.
Activity
rmcdaniel commentedon Nov 4, 2026
Taking #1018 on isolated branch
fix/1018-namespace-delete-reference-windowfrom mainc356ede6, after #1022 merged. No duplicate PR exists.The fixture tests payload ownership and namespace deletion, including refusal with unavailable storage. It does not need the PHP maintenance loop. I will record this fixture separately through the existing PHP-only SQLite maintenance window used for service-calls and schedule-catalog, keeping its exact reviewed
200/zero-pending assertions and recording all three targets once. Native maintenance stays enabled. MySQL/PostgreSQL coverage remains in the main corpus.Both the source runner and image qualification must keep the full fixture union and fail independently on the new record/comparison. Existing orchestration, selection and retry regressions will exercise that. This avoids treating
207as a pass or reissuing a delete after its namespace is already gone. A bounded published-reference run will check the unchanged fixture; full CI follows in a draft PR. This is CI reliability work while the separate 3.1.0 tag stop remains with Security.rmcdaniel commentedon Nov 4, 2026
Server open-item pass, 2026-11-04.
Owner: Server. The concrete fix is already isolated in PR #1024, not another retry rule: the unchanged SQLite namespace-delete fixture runs once per target through the existing PHP-only maintenance window, with restoration and independent failure fields. The exact 200/zero-pending assertions, 99-fixture union and native maintenance remain unchanged. The retained reference proof and Security disposition are linked on that PR; the short control did not reproduce the original flake and is not a measured flake-rate claim.
Next action is General's reconciliation of #1024's old release-sequence hold for a future maintained-main source refresh. The frozen release runner and original failed merge-group recording stay intact. I have cross-linked this issue to its implementation rather than submitting a duplicate or accepting 207/pending as success.