Repository navigation
Send a durable request_id on signals and updates and expose it on failures - #198
Merged
Merged
Conversation
…lures Part of durable-workflow/.github#216 (safe signal/update retries after a lost response). Work in progress; see the draft PR body for the remaining steps. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This was referenced Oct 20, 2026
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Safe command retries
Part of shared #216. The client generates one body
request_idfor each logical signal/update when omitted, preserves it through transport retries, returns it on receipts, and exposes it on typed signal/update failures. A repeated command with the same key must retain its original decision; a changed intent receives the typed conflict.X-Request-Idremains correlation.The concrete live/test handles accept a trailing optional key while the published
WorkflowHandleInterface::signalsignature remains unchanged. Review reproduced a real fatal error for an existing custom handle implementation against the inherited draft at e8dfe49; the correction preserves that implementation and the concrete keyed API. It needs no additional breaking interface change.PHP f4d40fa also preserves the released Server's maximum 255 Unicode characters, rather than narrowing it to 255 bytes. The tests-first 326de19 control fails before that correction. Native PCRE counts code points without adding mbstring. Empty, invalid UTF-8 and over-limit keys refuse before sending. ASCII and Unicode boundary controls preserve exact request bytes.
Latest local selection passes 12 tests / 75 assertions, including transport failures, retained/conflicting receipts, selected handles, Unicode limits and a real separately executed legacy-interface consumer. Focused five-file PHPStan passes. Earlier test/static runner failures stay recorded separately. Normal exact-source CI and full suites remain required.
The canonical contract is shared #216. Core/Server admission, concurrent and lossy-response qualification, CHANGELOGs, all eight documentation locales, immutable publications and normal installed consumers remain pending. PHP 2.5.4 is published and its entry-safety installed slice passes; this draft makes no safe-retry release claim. Cleanup #111/PHP 3 and optional tracing #199 proceed independently, with conflicts resolved and the combined source requalified at integration.