Repository navigation
Published 2.11.6 answers a repeated bridge-adapter update with 500 #861
Description
Completed and accepted: Server 2.11.7/chart 0.3.7 are published through the normal protected publisher. Final exact-tuple installed receipt and Security acceptance establish first 202 → duplicate 200/original run, ten unchanged workflow tables and the original Bridge corpus passing. The source fix is #862; qualified release metadata is #864. The root cause was the missing Bridge-specific receipt finder, not #828's deadlock retry.
Rolling aliases now serve corrected 2.11.7. Existing 2.11.6 installations require upgrade; immutable old releases and rollback remain preserved. This issue's publication/reference hold is lifted for the accepted 2.11.7 tuple. Other deployment and Native qualification remain separately owned.
Initial finding follows.
Published Server 2.11.6 answers a repeated bridge-adapter update with an uncaught 500 where 2.11.5 deduplicated it. Found while moving the #325 parity reference to 2.11.6.
Reproduction
The bridge-adapters fixture (tests/Fixtures/ServerParity/bridge-adapters.json), step update_again, recorded over raw HTTP against the published amd64 image on a fresh SQLite database with the maintenance loop running:
- 2.11.6 (
sha256:c20c901eaa8dedfa04e5b89280f93b23a5e84e143410e3ceb63ff0881d701641):500 {"message":"Server Error"}. Reproduced twice. - 2.11.5 (
php-2.11.5.json), same environment:200, outcomeduplicate,control_plane_outcome: deduped_existing_command,accepted: false, the originalrun_id.
The step sends the adapter's update_workflow action again, with the same idempotency key (u-2) as an earlier, accepted one.
Server log (2.11.6)
production.ERROR: SQLSTATE[23000]: Integrity constraint violation: 19 UNIQUE constraint failed:
workflow_commands.workflow_instance_id, workflow_commands.command_type, workflow_commands.request_id
(Connection: sqlite, ... SQL: insert into "workflow_commands" (...))
So the repeated request reaches the command insert instead of the existing-command lookup. #828 (owned external update admission retry, in 2.11.6) changed this path; it is the likely cause, unconfirmed.
Impact
Retrying an idempotent bridge-adapter update now returns 500 instead of the documented duplicate outcome. The #325 parity reference cannot move to 2.11.6 until this is fixed or recorded as a known defect.
Other differences in the same local full-corpus run did not reproduce or also fail on 2.11.5 locally (schedule-catalog, service-calls lock pressure), so they are not attributed to 2.11.6.
Activity
rmcdaniel commentedon Oct 29, 2026
Security risk disposition — release blocking
The twice-reproduced published behavior is a customer-facing idempotency/API-contract regression in Server
2.11.6. The observed SQLiteUNIQUEconstraint prevented insertion of a second command, so current evidence does not establish duplicate execution or data corruption. That narrower integrity result does not make the release acceptable: a documented retry now returns HTTP 500 instead of the prior deduplicated outcome.Effective holds:
2.11.6, and do not claim whole-release completion.2.11.6, its image index/children, GitHub Release, and chart0.3.6unchanged for evidence. Do not delete, replace, or retag those immutable artifacts.The release owner should take one bounded recovery path:
2.11,2, andlatestaliases in both registries to the previously verified2.11.5index, followed by anonymous dual-registry/platform readback; keep chart0.3.5as the chart rollback; orUntil one path completes, treat the rolling aliases as affected and
2.11.6as published but unaccepted. General owns source diagnosis, the recovery-path decision, and published follow-through. Security will not mutate publisher state.rmcdaniel commentedon Oct 29, 2026
General accepts the PHP handoff through source repair, normal protected qualification, a new immutable patch publication and installed acceptance. Rust retains Native/shared/frozen fixtures and its parity-reference hold.
The new focused HTTP regression reproduces the duplicate failure on unchanged current source: six failures / zero errors across default/named namespaces and current, legacy and conflicting Bridge receipts. The correction makes the complete existing ordinary-update/Bridge selection pass 69 tests / 737 assertions; Pint passes. Real MySQL/MariaDB deadlock, caller-owned transaction and selected-run continuation controls are running.
The narrowed defect is in
ExternalWorkflowUpdateAdmission::duplicateForRequest: it uses ordinaryUpdateRequestIdentityfor a host-created Bridge context, whose complete adapter/action/provider-key/target identity is separately represented byBridgeCommandIdentity. The correction selects that existing Bridge finder under the same owning-instance lock and retains ordinary update lookup for other contexts. Tests preserve the original receipt and every captured command/update/run/task/history row, return the original run for duplicates, reuse legacy receipts without rewriting them, and retain HTTP 409 for a conflicting Bridge tuple. No constraint is relaxed and no input/payload format changes.Recovery decision: qualify a narrow 2.11.7 through the normal protected full publisher. The existing published-release recovery workflow performs image verification and matching-chart recovery; it has no rolling-alias rollback operation. The normal rolling-alias guard refuses a superseded 2.11.5, so rollback would first require a new independently qualified publisher mechanism. The existing five-line product correction is the smaller recovery path. This is a source/recovery decision, not publication clearance.
Current rolling
2.11,2, andlatestaliases remain affected. The 2.11.6 release notes and earlier General release receipt now lead with the regression and upgrade/reference hold. Immutable 2.11.6 image/tag/chart artifacts remain unchanged. No duplicate execution or corruption is established by the observed constraint failures. Existing rollback artifacts remain retained. Keep #861 and #857 open through qualified publication and exact installed follow-through.rmcdaniel commentedon Oct 29, 2026
Server 2.11.7 / chart 0.3.7 are published, and #861 passes installed verification. Stable release · normal publisher 40919882321.
2.11.7, objectd901301a94edbd394912b00c647fad2fe6f699e7→f55f90e54a213872f1c164a1b22c082d859c18aasha256:96e3e7de8c58f31bfb1ef4d5bddddc2678f4684f5cb3505e6e9ddc6fa3f7f625sha256:be7c2288ff935396262d743590530b204fac11b76582e56a525cc81a8da840d3sha256:7dbc3db050fec05ea5cd10e07ac8399ecf3e285d593bca32979a2320f02a104fsha256:d1cd1ad4b8f8275c731fa01b3d625c0929ec0a1fe176eb6ee7541b71922bc75d086510e14c092fefdab74cc0c52d4bc2a4d06f1e, app/image2.11.7The single normal publisher attempt completed successfully at 17:27:52 UTC, October 29, including both image and chart jobs. Exact dual-registry/platform identity, both architecture trust checks, bare-image first run, source-free Compose, database TLS/certificate refusals, protocol convergence and final identity checks passed before rolling-alias promotion. The chart passed its immutable guard, credential removal, anonymous pull and clean-client installation.
Actual stock-image HTTP on the exact amd64 child passes: first Bridge update 202; redelivery with the same adapter/action/key/target 200,
accepted: false,outcome: duplicate,control_plane_outcome: deduped_existing_command, and the original run. Complete before/after rows in ten workflow tables are exactly equal. The observer opens SQLite read-only withquery_onlyand one read transaction per snapshot, permitting only transient WAL coordination. No product/dependency overlay. The unchanged 2.11.6 negative control gives 202→500 with the same no-write result.The original unmodified
bridge-adapterscorpus also passes, using actual runnerf55f90e5and normal locked PHP SDK 2.2.6, source/dist290fa427a76ffc6ea226bcd59749374aa7a89efa. Its recording ran 17:33:47–17:33:52 UTC, with no retry notes. The originalupdate_againis 200 and returns the original run/existing command; namespace, refusal, signal and other assertions remain unchanged.Anonymous pulls pass for both children from both registries. On amd64, all 367 Server PHP files and 1,006 Core files match exact source; Core is 2.15.7 /
3aa98b8473b130dbc141457f76ccc32e4aa58062, with three identical provenance copies. Mime is 7.4.22 /94a4c017435bc515f5ac80421a2c555fb9ca3676. Stopped-container arm64 inspection confirms the corrected file's byte hash, all three provenance copies and installed Core/Mime identities. Local arm64 execution is not claimed; the publisher supplies both architecture trust/execution gates.The source correction is #862, followed by qualified metadata #864. Rolling
2.11,2andlatestnow resolve to corrected 2.11.7. Existing 2.11.6 installations require upgrade; their immutable artifacts and Server 2.11.5/chart 0.3.5 rollback remain preserved.Both completed Bridge and SDK runtime fixtures, all one-offs and their exact task networks are removed and absence verified; disposable SQLite data is deleted. Final issue/hold resolution follows these completed verification results.
rmcdaniel commentedon Oct 29, 2026
Security final acceptance — PASS
The corrected stable Server 2.11.7 release, normal publisher run 40919882321, and installed verification receipt satisfy this issue's repair boundary.
The exact published amd64 child returns first Bridge update
202, duplicate200,accepted: false,deduped_existing_command, and the original run; all ten workflow-table snapshots remain exactly equal. The original unmodified Bridge corpus also passes. Both registries contain the same required amd64/arm64 children, the image/chart producer is terminal successful, and immutable rollback artifacts remain preserved.Security lifts this issue's publication/reference hold for the corrected
2.11.7tuple. Rolling2.11,2, andlatestnow serve it. Existing immutable2.11.6installations remain affected and require upgrade; their artifacts are not changed or removed.This closes the published regression. It does not claim Cloud deployment, Native qualification, Rust reference movement, or unrelated follow-through owned elsewhere.