Update-ending scope checkpoints return a next sequence that subsequent calls refuse

Completed on October 29: published Core 2.15.5 introduced the fix, and normal published Server 2.11.6/Core 2.15.7 passes the selected installed endpoint and PHP/Python/Rust consumer acceptance. Final exact-tuple receipt records 16 raw HTTP cases/440 assertions, the supported cancellation/prepared paths, and normal successful/failed update Workers with idempotent repeats. Python 2.12.1 also passes all 13 selected cancellation/prepared cases. No product overlay.

This completion is specific to #953. Server #861's separate bridge-repeat defect is accepted in published 2.11.7, and Workflow #956 is completed; Server #825 remains separate. No claim is made that the affected 2.11.6 release is globally accepted.

Earlier diagnosis and source/publication evidence follows.

General owns this confirmed PHP Core defect, discovered during the review of durable-workflow/server#822.

A cancellation-scope prefix ending in complete_update or fail_update commits successfully and returns an advanced next_sequence. The next checkpoint or scope-open under the retained claim refuses that exact returned sequence. A worker cannot safely follow the receipt.

Reproduced against the normal Composer-installed Core 2.15.2 and current published Core 2.15.4 (8af7a0c89be759dfd9eddeedc0f724bf4211a7cd) in a Laravel/SQLite harness. Each version ran eight cases with 32 assertions: four update-tail cases fail, four marker-after-update controls pass, and there are no test errors. This exercises Core's real bridge, models and scope API; installed SDK/HTTP acceptance remains outstanding.

Minimal sequence, for an accepted update and a live leased workflow task:

Call DefaultWorkflowTaskBridge::checkpointCancellationScopePrefix at sequence 1 with one complete_update command. The reply is checkpointed and returns next_sequence: 2; the update is completed.
Under the same unchanged claim, submit another prefix at sequence 2. Core returns cancellation_scope_checkpoint_sequence_mismatch.
Alternatively call CancellationScopeHistory::open at the returned sequence 2. Core throws cancellation_scope_sequence_mismatch.
fail_update has the same result. Append a version marker after the update in the original batch, and both follow-up controls succeed at the returned sequence 3.

The source explanation is shared with native: applyCompleteUpdate/applyFailUpdate advance the batch sequence, while WorkflowStepHistory::nextDurableCommandSequence intentionally excludes update events. A prefix ending in an update therefore returns a position its history does not reconstruct. The same-batch sequence correction in Server #822 matches PHP Core; this is not evidence of a native-only regression.

Acceptance:

Make returned checkpoint positions and subsequent scope/checkpoint admission consistent under the retained claim for both successful and failed update tails, including a preceding workflow command and multiple checkpoints.
Preserve update replay semantics and the separation between update history and the workflow's yielded-command identities. Do not simply reinterpret every update event as a workflow step.
Preserve duplicate receipts, claim fencing, rollback and closed/deadline refusals. Add before/after regression controls for both follow-up operations and confirm cold replay.
Qualify the fix, publish through the normal Core path, and complete Server and affected SDK acceptance with exact published artifacts. Coordinate the native contract follow-through with Server Profile embedded replay growth before retained execution #822/Cancel running Workflows via Signal #325.

Current source: PR #955 merged as 164599419ec4cef275927ad23da1db81233dc514, exact head fa606fdf6c14de9311027f2b6356f8484cd0ff37. The runtime implementation remains unchanged from 0cc6f815.

All five required quality commands passed at ca945fc7 / tree 82e2f3e9, identical to the prior integration head 8e5dc835: full ECS/PHPStan; 5,160 unit tests / 72,751 assertions; coverage 5,160 / 72,850 with 77.24% (59,232 / 76,684), passing the 60% ratchet; PostgreSQL 17.11 / Redis feature qualification 2,545 / 24,996. Zero failures/errors; unit/coverage have 43 skips and 15 notices; features have 18 skips. The 100% target remains unmet. Full qualification and failed-run dispositions.

The first hosted MySQL run found 24 order-only failures in the duplicate-receipt assertion. The test now sorts top-level object keys before strict comparison, preserving every value/type and nested list order. Independent MySQL 8.0.46 qualification passes the 32 focused and five official replay cases: 37 tests / 1,677 assertions, no failures/errors/skips. The original test reproduces 24 order failures; the original bridge with the corrected test still produces 24 expected cursor failures and eight passing controls, with no errors/skips. Exact correction and evidence. Fresh hosted qualification at fa606fdf passed before merge.

The only follow-up changes to the fully qualified tree are the portable test comparison and composer.json source-release metadata 2.15.5. The committed source-release/qualified-package contract passes one test / 42 assertions. Full current-main qualification passed23jobs/two conditional skips. Core2.15.5 is published at exactmain16459941; Packagist source/dist match that commit. Normal Release Verification40698403615 passes the published-package contract and all16supported Laravel/PHP published-upgrade jobs. Exact affected Server/consumer acceptance remains incomplete.

The corpus counterfactual retains its original proof: one new fixture (80 to 81 replay cases), original bridge cursor3 versus expected2 with zero errors. Earlier failed runner/profile and legacy-fixture outcomes remain separately recorded. #954/#496 is independently accepted and closed.

Server integration PR #839 merged as 7f233a8db0318db290b28c4dd61a60886ecbde19 at 2026-10-28 14:46:16 UTC, exact reviewed head ded27cc1808206e4d2850d514ce98979ef074246. Required head checks and merge-queue PHP/shared-fixture/public-boundary checks all passed. It pins normal published Core 2.15.5 and adds 16 actual HTTP checkpoint/follow-up cases. Core 2.15.4 produces eight expected cursor failures and eight passing controls (16 tests / 204 assertions, zero errors/skips). Core 2.15.5 passes all 16 / 296; broader prepared/cooperative HTTP suites pass 115 / 6,501, zero failures/errors/skips. Only Core changes in the Composer lockfile.

Main PHP qualification 40709228190 passes at that exact merge.

Follow-up Server #843 merged at 9fc29d437b8198c24d426659543a9f59506f35f1, updating the normal Core pin to published 2.15.6. The combined HTTP/checkpoint/library suite passes 293 tests / 11,881 assertions, with eight database-specific SQLite skips; PostgreSQL regression and all repair mutations pass eight / 192 without skips. Required merge-group PHP/shared-fixture/Sonar checks passed. Main PHP feature/readiness/TLS qualification passed. The aggregate fails only on the newly corrected Symfony Mime dependency audit, addressed by #845/#846.

Next: qualify the affected HTTP and supported SDK paths using the exact published Server image that contains the fix. The consumer inventory and selected acceptance experiments are recorded in the follow-through comment. Keep this issue open through published consumer acceptance; source HTTP tests are not installed Server/SDK evidence.

General's source correction is pushed at 0cc6f81538002d264cb93d8882e27153be532541 on fix/953-update-tail-checkpoint-sequence.

Flat local/scope prefix receipts now return the authored cursor before any trailing update outcomes. Positions within mixed command batches remain unchanged, and update events are not added to workflow-step history. A retry of an older bad receipt corrects its returned cursor from the original fingerprint-validated commands, preserving its commit time, claim and side effects. It neither reapplies the batch nor follows history recorded after the checkpoint. Prepared local-group reservation receipts retain their separate semantics.

Actual regression evidence on PHP8.3.36/Laravel13.39.0:

Candidate: 32 tests / 308 assertions, PASS. Successful/failed updates, both flat prefix kinds, metadata before/after the update, subsequent prefix and scope opening, unchanged duplicate/claim state, old receipts after later history and fresh FiberRunner replay are covered.
Original 8af7a0c8 bridge with the same new tests: 32 tests / 136 assertions, 24 failures / eight passing controls, zero errors.
Changed-file ECS passes. Full PHPStan passes with a1GiB analyser limit. Full-repository style, unit, unit coverage and feature qualification are still pending or running. Earlier local setup/tool-capacity failures are not passes.

Impact scope is narrower than a demonstrated SDK outage: the current published PHP SDK3.6.1 allows only metadata in retained prefixes and handles updates in a separate turn. Its ordinary path was not shown to emit the failing update prefix. This remains a confirmed Core API contract defect; current installed SDK/HTTP impact and published-fix acceptance are separate gates.

No PR, release or installed fix is claimed. New product PR delivery remains behind the measured CI bottleneck work. General owns the remaining qualification and protected delivery, followed by published consumer and native contract follow-through.

Cloud compatibility review of exact source 0cc6f81538002d264cb93d8882e27153be532541: no additional compatibility issue found in the reviewed cursor and legacy-receipt paths.

The duplicate repair remains behind the existing run/task binding, leased status, lease owner/attempt, lease expiry and run-deadline checks. Matching the checkpoint ID alone is insufficient: start sequence and the original parsed-command fingerprint must also match. The repair only changes the returned receipt. It does not enter command application, persist a new receipt, renew the claim or recompute from later history.

The trailing-outcome adjustment agrees with WorkflowStepHistory::nextDurableCommandSequence, which excludes update events from authored workflow-step identities. An update before a later workflow command keeps its existing in-batch position; only trailing update outcomes are omitted from the returned cursor. Prepared local-group receipts retain their separate reservation behavior.

Review scope: the exact diff, surrounding checkpoint admission/duplicate logic, update application, authoritative step calculation and the new regression module. I did not independently rerun PHP/database tests or verify a published installation. The owner's executable evidence, remaining full qualification, Security review and published/native follow-through retain their stated scope.

Security defensive review of exact 0cc6f81538002d264cb93d8882e27153be532541: no additional finding in the reviewed cursor/legacy-receipt boundary.

Duplicate correction remains behind locked run/task binding, the active leased workflow claim, exact owner/attempt, unexpired lease, run/deadline checks, and exact checkpoint/start/fingerprint matching.
The correction is response-local. It derives only from the fingerprint-matched original parsed commands; it does not apply commands, persist state, renew the claim, or follow later history.
Only trailing complete_update / fail_update outcomes are removed from the returned authored-step cursor. Mixed positions remain unchanged, and prepared local-activity groups are excluded.
Fresh update application still uses the existing run-bound accepted-update validation and transaction rollback path. Existing checkpoint tests cover stale owner/attempt, sequence, and fingerprint refusal.

This was a source-and-test review only. I did not rerun PHP/database/published-artifact acceptance; the owning qualification, publication, and downstream-native gates remain.

At unchanged source 0cc6f81538002d264cb93d8882e27153be532541, the full unit suite now passes: 5,157 tests / 72,522 assertions / 0 errors / 0 failures, with 43 skips and 15 PHPUnit notices. This was a file-backed SQLite run with synchronous queues and array cache. The earlier incorrectly configured Redis queue/cache run produced 10 failures and one error; those results remain retained as test-environment evidence. All 97 tests in its previously failing classes separately passed after correcting the configuration (894 assertions).

Full ECS and PHPStan checks passed. The focused 32-case regression remains 32/308 passing on the fix versus 24 failures and eight passes against the original bridge. Security's review and Cloud's compatibility review found no additional issue in their stated source-review scope; neither claims independent runtime qualification.

Coverage, feature qualification, protected PR checks, release and published-consumer/native follow-through remain pending. No PR or tag has been created while the CI throughput repair is in progress.

Local composer coverage finished successfully on unchanged application source 0cc6f81538002d264cb93d8882e27153be532541. The V2 line-coverage gate reports 77.24% (59,232 / 76,684 lines), above its accepted 60% baseline. The 100% target is not reached.

Full feature qualification is now running against isolated PostgreSQL 17.11 with the suite's Redis queue/cache configuration. It remains live and incomplete. The full unit suite, ECS, PHPStan, focused regression and source-review evidence remain as recorded in the prior qualification receipt. No release or full qualification claim is made while feature and hosted/downstream gates remain pending.

General qualification update for source 0cc6f81538002d264cb93d8882e27153be532541:

The full feature run was runner-blocked. PostgreSQL's 512 MB container limit OOM-killed a database process; PostgreSQL logged signal 9 and recovery, and its cgroup recorded one OOM kill. The resulting run finished with 2,545 tests, 19,887 assertions, 561 connection errors, zero assertion failures, 18 skips and seven risky tests. All 561 errors were database recovery/unavailable connection errors. This is not a passing feature qualification.

The fixture limit is now 2 GB. PostgreSQL recovered and passed readiness, and the same unchanged source is undergoing a fresh full feature run. The original failed result is retained. The existing full unit, style, PHPStan and coverage results remain separate: 5,157 unit tests passed, and V2 line coverage passed the 60% ratchet at 77.24% (59,232 / 76,684); the 100% target is not reached.

Next: finish the corrected feature run, then advance the normal PR/release and published-consumer follow-through when the current Server CI repair has measured evidence. No PR or tag has been opened for this change yet.

General completed the required local quality cycle at unchanged pushed source 0cc6f81538002d264cb93d8882e27153be532541.

Focused checkpoint/duplicate-receipt regression: 32 tests / 308 assertions pass. Against the original bridge, the same cases produced 24 failures and eight passing controls, with no test errors.
Full ECS and PHPStan pass.
Full unit suite: 5,157 tests / 72,522 assertions, zero failures/errors, 43 skips and 15 notices.
composer coverage: V2 line coverage 77.24% (59,232 / 76,684), passing the 60% ratchet. The 100% target remains unmet.
Corrected full PostgreSQL 17.11 / Redis feature run: 2,545 tests / 24,983 assertions, zero failures/errors, 18 skips, exit 0, in 1,747.09 seconds. This profile's skipped conditional tests are not claimed as executed.

The PostgreSQL memory limit was 2 GB for that passing run. Its OOM counter remained at the one kill from the earlier 512 MB runner failure, with no additional kill. The original runner-blocked result remains separate. Product source and the tracked tree stayed unchanged across qualification. Existing Cloud and Security reviews were source reviews, not executable acceptance.

Next: advance the normal PR/release once the current Server CI repair has measured evidence, then verify the exact published Core and affected Server consumer. No PR/tag/release or installed acceptance is claimed. Current PHP SDK 3.6.1 does not emit these update-tail prefixes; the reproducer exercises Core's valid bridge/API contract, not an observed SDK-worker outage.

Cleanup verified: task-owned PostgreSQL/Redis containers and their network are removed, with no containers left under the task label. Duplicate generated reports were removed; remaining small diagnostics are retained only through published acceptance or issue disposition.

General pushed f24c435aeb8e0105102551196c1c87f8d61f2086 with the required append-only replay fixture, update-tail-checkpoint-cursor.

The retained history and worker prefix describe a version marker followed by a completed update, then another marker admitted at the returned cursor. Both the cold replay outcome and live checkpoint/follow-up are exercised through the existing official consumers. The new test workflow is also staged into the old-source consumer, so the counterfactual receives the same fixture support.

Evidence:

Current focused and corpus consumers: 115 tests / 4,578 assertions, no failures, errors, skips or warnings.
With only the bridge replaced by original published 8af7a0c8: 83 corpus tests / 4,042 assertions, exactly one expected failure, no errors. The failure is the returned cursor 3 versus expected 2.
Official corpus validation against 8af7a0c8 passes: replay evidence grows from 80 to 81, with one counterfactual fixture verified; codec evidence remains 38. All 67 corpus-policy tests pass.
Full ECS (1,556 PHP files) and full PHPStan pass.

Runtime implementation is unchanged from 0cc6f815. Its earlier full-suite results remain the results of that revision. Fresh full unit, coverage and PostgreSQL/Redis feature qualification are running for this expanded candidate; they are not yet claimed as passed. The normal PR/publication and exact published-consumer acceptance remain outstanding.

Combined head ca945fc7cc2db321a76c783352c7e895b8b9f6d4 now passes full ECS, full PHPStan, the full unit suite and the corrected full PostgreSQL feature suite. The runtime implementation remains the reviewed 0cc6f815; this head includes the required replay corpus and the independent test-fixture correction from #954.

Full unit suite: 5,160 tests / 72,751 assertions, zero failures/errors, 43 skips and 15 notices, in 1,204.10 seconds.
Full PostgreSQL 17.11 / Redis feature suite: 2,545 tests / 24,996 assertions, zero failures/errors and 18 skips, in 2,167.07 seconds, exit 0.
PostgreSQL used a 2 GB limit and recorded zero OOM events/kills. The first combined ECS invocation hit the image's default 128 MB PHP limit; a task-only 1 GB limit passed with no source changes. That failed runner result is retained separately.

The earlier expanded-corpus feature failure is preserved. Its remaining queue-budget fixture is now independently accepted in #496: deterministic before/after controls on PostgreSQL and MySQL, plus the fully green main Build after #954.

composer coverage is still running on this combined head, so the five-command quality cycle is not yet complete. The completed feature results are retained with matching hashes; its exact task-owned database/Redis fixtures and auxiliary checkout can now be removed while coverage uses its separate Redis. Next: finish coverage, integrate current main, advance the normal runtime PR/release, then verify the exact published package and affected Server consumer. No runtime PR/tag or installed acceptance is claimed.

All five required quality commands pass at ca945fc7cc2db321a76c783352c7e895b8b9f6d4:

Full ECS and PHPStan: no errors.
composer unit: 5,160 tests / 72,751 assertions, zero failures/errors, 43 skips and 15 notices.
composer coverage: 5,160 tests / 72,850 assertions, zero failures/errors, 43 skips and 15 notices; V2 line coverage 77.24% (59,232 / 76,684), passing the 60% ratchet. The 100% target remains unmet.
composer feature: PostgreSQL 17.11 / Redis, 2,545 tests / 24,996 assertions, zero failures/errors, 18 skips and exit 0. The database had zero OOM events/kills.

Integrated accepted main d8b7833d afterward as pushed head 8e5dc83537732ccc35a121bf74c04bdd0d74af86. Both commits have the exact same Git tree, 82e2f3e97f0ad663014fa95e7381f2c9826ef0a8. The integration changes history only; the qualified source bytes are unchanged. The runtime implementation remains 0cc6f815, with the required replay corpus and independently accepted #954 fixture correction.

The earlier runner-profile failures and the expanded-corpus feature failure remain separately recorded with their dispositions. #496's final acceptance includes direct PostgreSQL/MySQL counterfactuals and the green full main Build. Completed feature fixtures and its auxiliary checkout are removed. The remaining completed coverage fixture and duplicate bulk coverage XML can now be removed after this receipt, retaining the small totals and current source diagnostics.

Next: normal runtime PR/review once the current General Server PR's CI completes, then the normal stable release and exact published-package/Server acceptance. The stable tag must match committed source release metadata and pass the published-package contract. No runtime PR/tag, package publication or installed acceptance is claimed by this local qualification.

Published Core 2.15.5 from exact qualified main 164599419ec4cef275927ad23da1db81233dc514 at 13:39:11 UTC. The annotated tag dereferences to that commit; its committed product-train is 2.15.5. Packagist now advertises version 2.15.5 / normalized 2.15.5.0, with source and distribution both pinned to the same commit.

Before tagging, full main build40695277985 passed 23 jobs with two conditional skips, covering current quality/coverage/SQL qualification. The committed release-metadata contract passes 1 / 42. Normal Release Verification40698403615 is terminal success: published-package/platform-contract verification plus all 16 supported Laravel/PHP published-upgrade jobs pass, with no failures/skips.

The MySQL-specific corrected regression and official replay consumers pass 37 / 1,677. The original bridge with the corrected test still fails 24 cursor cases and passes eight controls, without errors/skips. The initial order-only MySQL test failure and its correction remain in the PR receipt.

Keep #953 open. Next: integrate the normal published 2.15.5 dependency into Server source, qualify the affected retained-prefix HTTP/SDK paths, and complete exact published Server/consumer acceptance through its owning publication path. The existing Server 2.11.5 artifact does not acquire this Core update from this package release. No new Server image/tag/dispatch is part of this delivery.

General's published-release follow-through, 2026-10-28:

Server #839, head ded27cc1808206e4d2850d514ce98979ef074246, updates the normal exact Composer pin and lock to Core 2.15.5 (164599419ec4cef275927ad23da1db81233dc514). No other locked package changes. Its 16 HTTP cases cross both checkpoint routes, both update outcomes, duplicate requests and subsequent checkpoint/scope admission, with marker-after-update controls and unchanged-lease assertions.

Original normal Core 2.15.4: 16 tests / 204 assertions, eight expected cursor failures and eight passing controls, zero errors/skips.
Normal published Core 2.15.5: 16 / 296 pass, zero errors/skips.
Both complete prepared-local-activity and cooperative-cancellation HTTP suites: 115 / 6,501 pass, zero failures/errors/skips. Changed-file Pint passes.

These are Laravel HTTP source tests against the published Core package. They do not establish a published Server image or real SDK Worker execution.

Consumer inventory from freshly fetched target branches:

Consumer	Dependency and affected behavior	Follow-through
Server main `536c41de`	Runtime exact Core 2.15.4 pin and lock. Exposes the affected retained-prefix routes. Published Server 2.11.5 still contains Core 2.15.1.	#839 source integration, then a normally published Server image and exact-image acceptance. An existing image cannot gain this fix from the Core tag alone.
PHP SDK 3.6.1 / Python SDK 2.12.0 / Rust SDK 4.10.1	No Core package dependency. The published PHP/Python worker prefix allowlists exclude `complete_update` and `fail_update`; Rust has scope open/prepare/deliver consumers, without a retained-prefix checkpoint producer in the inspected source.	No SDK release merely to match the Core version. Exercise supported retained-claim/cancellation and update paths against the new published Server tuple; preserve the distinction between raw HTTP regression cases and actual SDK worker coverage.
Waterline main `530ba717`	Core 2.5.12 is a development-only dependency. Waterline's production package has no Core runtime pin and does not emit these checkpoint requests.	No production package release needed for this cursor fix. Its history-display cursor is a separate API contract.
Sample App main `40be451c`	Runtime Core `^2.0`, lock 2.11.3. No affected retained-prefix calls in inspected application/routes/tests; its welcome workflow uses an ordinary remote activity.	The constraint permits 2.15.5. This change does not require new Sample App source behavior. Its existing lock remains explicitly older and must be updated/qualified before claiming that installation contains this fix.
AI main `fbdc2c98`	Runtime Core `^2.0`; no package lock or checkpoint consumer.	Fresh dependency resolution permits 2.15.5. No AI code/package release for this retained-worker endpoint fix.
CLI main `03ec028a`	No Core runtime dependency or retained-prefix producer.	No CLI release for this fix.

Deployed-application assessment is coordinated privately with its owner rather than inferred from repository pins.

Selected acceptance follows the conformance runbook and its SDK coverage inventory: the focused successful/failed update-tail and marker controls with duplicate/fence checks, plus supported cancellation-scope/prepared-local-activity and workflow-update SDK paths. Record actual PHP/Python/Rust execution separately. Core's published embedded upgrade matrix already passes; it does not substitute for the affected service-mode tuple. Keep #953 open until the required published Server/consumer result is recorded.

General's Server integration is merged: Server #839, exact reviewed head ded27cc1808206e4d2850d514ce98979ef074246, merge 7f233a8db0318db290b28c4dd61a60886ecbde19 at 2026-10-28 14:46:16 UTC. The merge group contains only the exact Composer dependency/lock update and the HTTP regression test file.

Required head checks and the merge queue all passed: PHP qualification, shared-fixture result and public-boundary checks. Main PHP qualification also passes at that exact merge. Security review has no findings or additional gate. The completed remote head branch was deleted with an exact-head lease and verified absent.

Normal published Core 2.15.5 is now pinned in Server source. Local HTTP evidence remains 16 focused tests / 296 assertions and 115 related tests / 6,501 assertions, zero failures/errors/skips, with the original Core's eight expected cursor failures and eight passing controls separately retained.

#953 stays open for the exact published Server image and supported SDK/consumer acceptance selected in the follow-through inventory. These source and package results do not establish that image/SDK result.

Installed-image candidate follow-through, 2026-10-29: the uploaded Server 2.11.6 amd64 image containing published Core 2.15.7 passes all 16 raw HTTP update-tail cases / 440 assertions, with zero failures, errors or skips. The exact unchanged image/source tuple and candidate scope apply here too; normal release gates remain pending Server #857/#859.

The cases cross both local-activities/checkpoint and cancellation-scopes/checkpoint, successful and failed updates, subsequent checkpoint and scope-open, and marker-after-update controls. Every update is accepted through the real public API before the task is claimed; no update/history rows are seeded. Duplicate checkpoint receipts preserve the full returned history. The original claim's status, owner, attempt and exact expiry remain unchanged in read-only database snapshots. Repeating the original update request reads the same update ID and its completed result or expected failed receipt. All follow-up operations use the returned checkpoint position.

Published PHP SDK 3.6.1, Composer source/dist 2a44993761b1b900d3f631c0b13dccb8b45ddf5e, also has passing results for all 15 selected cooperative variants: canonical retained-claim scope receipts and pagination, live/cold timer cancellation, pre-claim duplicate/lost-reply delivery, local callback stopping, prepared-local backend attempts, SIGKILL cleanup recovery, and prepared groups. The original published fixture run passed 14 of 15; its custom lost-reply transport omitted the SDK's required independent activity-lease bootstrap. An owned fixture copy adds that setup without changing assertions or installed SDK code; both affected variants then pass 2 tests / 53 assertions. The correction retains the fault-injecting workflow transport and supplies the independent helper's matching runtime, namespace, protocol and authentication.

The raw endpoint observer initially assumed a heartbeat field that this response does not expose and HTTP 200 for an intentionally failed update. The final observer instead reads the unchanged claim directly and expects the documented failed-update HTTP 422. The final 16-case result above includes the outcome checks. Those setup/observer failures are not product regressions.

These are separate scopes: PHP/Python's published worker prefix allowlists do not emit update-completion tails, so the 16 raw cases do not claim SDK authoring coverage for that unsupported combination. Published Python and Rust consumer follow-through and normal Server release acceptance remain outstanding. Keep #953 open.

Additional installed SDK results: published Python 2.12.0 passes 13 selected cancellation/prepared-local cases, zero failures/errors/skips, including sequential callbacks, nested mixed groups, and SIGKILL cleanup recovery across the original 30-second deadline. All 39 installed runtime Python files match release commit 14dc458d71f42f915de748e708beb159384160d7. The owned prepared-test fixture admits this selected published runtime through an explicit opt-in while preserving every capability and behavior assertion; Native-only qualification flags remain unset.

Published PHP SDK 3.6.1 actual Workers also pass successful/failed update handlers and idempotent request repeats: 2 tests / 41 assertions, zero failures/errors/skips. Each root then consumes its finish signal and completes once. The canonical terminal update event is UpdateCompleted for both outcomes, with failure metadata for the failed handler; the observer was corrected from its initial incorrect UpdateFailed event assumption. These results remain candidate evidence; Rust SDK follow-through and accepted normal publication are still outstanding.

Published Rust SDK 4.10.1 now has passing results for all five selected cancellation cases: request before claim, waiting timer, duplicate request/deadline retention, earlier side-effect ordering, and cold successor saga cleanup within the original budget. The normal crates.io package checksum matches Cargo.lock, VCS commit matches tag ebad5c1b729c4f4c728b03de4e7d7d3c915fd8e1, and all 61 installed runtime/schema files match that source. The published cold-cleanup test fixture initially attempted to register the same workflow twice, correctly triggering the SDK registration guard before network execution. The owned fixture now constructs each Worker once and registers only its intended handler, preserving every assertion; that fifth case then passes with zero ignored tests. The other four passed unchanged.

A further Python concurrent-signal consumer check found SDK Python #223. It reproduces identically on unchanged Server 2.11.5/Core2.15.1 and the 2.11.6 candidate/Core2.15.7; the after-completion control passes on both. It is not evidence of a new Server regression and does not invalidate the passing cursor/cancellation cases above, but its affected installed replay acceptance remains separately open under Workflow #956. Normal release gates still remain necessary before this issue's final published-tuple acceptance.

The #953 cursor fix is delivered through published Core and verified with the selected published Server/SDK consumers. This acceptance is specific to #953. The unrelated Server #861 bridge-repeat regression and its deployment/reference hold remain open.

Core 2.15.5 introduced the fix at 164599419ec4cef275927ad23da1db81233dc514; Server 2.11.6 includes normal published Core 2.15.7 at 3aa98b8473b130dbc141457f76ccc32e4aa58062. The exact installed Server source is d13ebdb5eccc3d33b9d3c0e1ebc9ab0cb116e121, amd64 image sha256:c20c901eaa8dedfa04e5b89280f93b23a5e84e143410e3ceb63ff0881d701641. Normal protected release verification 40885194236 succeeded without rebuilding the immutable images, including architecture trust, first-run/Compose/database-TLS/protocol gates and the matching chart. That publication does not globally accept 2.11.6 after #861 was found.

Installed endpoint evidence passes 16 real HTTP cases / 440 assertions, zero failures/errors/skips. Both checkpoint routes, successful/failed update tails, subsequent checkpoint/scope-open, multiple checkpoints and marker controls use real accepted updates and the returned positions. Duplicate receipts preserve canonical history, and read-only snapshots preserve the original claim's owner, status, attempt and exact expiry. No update or history rows are seeded.

The selected real Worker paths are now complete on that same stock Server image:

Published SDK	Installed acceptance
PHP 3.6.1, source/dist `2a44993761b1b900d3f631c0b13dccb8b45ddf5e`	15 selected cancellation/prepared variants plus 2 normal successful/failed update Worker cases / 41 assertions.
Python 2.12.1, release `c47ef37aa0daf2c5ef3e45ee1ed180daf18596b1`	13 selected cancellation/prepared cases (143.62 seconds, zero failures/errors/skips, one fixture-marker warning) plus 2 normal successful/failed update Worker cases. All 39 installed runtime files match the published release.
Rust 4.10.1, release `ebad5c1b729c4f4c728b03de4e7d7d3c915fd8e1`	5 selected cancellation/cold-cleanup cases plus 2 normal successful/failed update Worker cases; no ignored cases in these selected runs. The normal crate checksum and all 61 runtime/schema files match the release.

The new Python/Rust update checks use ordinary SDK Worker loops and real transport. Each repeats the same request key and verifies one terminal UpdateCompleted event, the expected result 42 or expected handler failure, then a finish signal and one successful workflow completion. PHP/Python receipts and Rust failure receipts preserve update identity/closure; Rust compares the exact history before and after both successful and failed repeats. The initial observer expected an optional retained field that this Server does not return and omitted Python's handler-failure prefix; the corrected assertions retain durable identity/history checks without changing SDK or Server code. The first Python cancellation invocation lacked pytest's async mode and failed before executing network cases; the corrected invocation runs all 13 cases. No product overlay or changed runtime limits.

As recorded in the consumer inventory, PHP/Python prefix allowlists do not author update-completion tails, and inspected Rust has no retained-prefix checkpoint producer. The raw endpoint regression tests and supported SDK Worker tests therefore establish separate scopes. No unchanged SDK release was needed for this cursor fix. Python 2.12.1 separately delivers SDK #223; its signal-receiver fix does not close Workflow #956. The other consumer dispositions remain explicit in the linked inventory; no claim is made that the Sample App's older lock contains the Core correction.

The published Core upgrade matrix and source counterfactual/fencing/replay evidence remain linked above. Closing #953 as completed; #956, Server #825 and the #861/#857 release follow-through remain independently owned and open.

Navigation Menu

Repository navigation

Update-ending scope checkpoints return a next sequence that subsequent calls refuse #953

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Update-ending scope checkpoints return a next sequence that subsequent calls refuse #953

Description

Activity

rmcdaniel commented on Oct 27, 2026

rmcdaniel commented on Oct 27, 2026

rmcdaniel commented on Oct 27, 2026

rmcdaniel commented on Oct 27, 2026

rmcdaniel commented on Oct 27, 2026

rmcdaniel commented on Oct 28, 2026

rmcdaniel commented on Oct 28, 2026

rmcdaniel commented on Oct 28, 2026

rmcdaniel commented on Oct 28, 2026

rmcdaniel commented on Oct 28, 2026

rmcdaniel commented on Oct 28, 2026

rmcdaniel commented on Oct 28, 2026

rmcdaniel commented on Oct 28, 2026

rmcdaniel commented on Oct 29, 2026

rmcdaniel commented on Oct 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions