Repository navigation
Replay redriven memo, search-attribute and signal-wait events at their reused time #244
Description
Follow-up to #240, from the Workflow 2.19.0 review.
Gap
Workflow 2.19.0 lets redrive reuse more completed steps:
- workflow#1001 reuses
MemoUpsertedandSearchAttributesUpserted. - workflow#1002 reuses an applied signal wait:
SignalWaitOpened,SignalReceivedandSignalApplied.
On the successor run these events carry reused_from_run_id and reused_recorded_at. Core replays now() after them at reused_recorded_at, via RedriveReplayClock::recordedAt().
The 2.19.0 notes say service-mode SDKs are not yet qualified for these events. If this SDK takes replay time from recorded_at or timestamp on any of these five events, a redriven workflow's now() after an upsert or signal wait comes out as the redrive time, not the source run's time. #240 only covered side effects, markers, timers and start time.
Done when
- For each of the five event types, replay time prefers
payload.reused_recorded_atwhen it is present. - Every event type this SDK actually replays has a regression fixture. It must be a redrive successor history with the reuse keys, and it must fail before the change and pass after it. Assert per-event provenance: each named event exists and carries both keys. A combined "any reused event" check isn't enough.
- If this SDK doesn't consume one of these events for time at all, say so with a test proving it, rather than skipping it silently.
- The SDK's regression-corpus policy guards any clock file you touch.
Ships in the next minor. Security reviews the exact head before merge.
Activity
Rebuild redrive fixtures as checked successor histories
Bind replay to recorded search-attribute values
Refuse unportable search attributes and rebuild the redrive fixture
Bind redrive successor checks to type, deadlines and reuse keys
Bind replay to recorded search-attribute values
Refuse unportable search attributes and rebuild the redrive fixture
Compare search attributes structurally and bound their lengths
Require a contiguous reused workflow-step prefix
Bind replay to recorded search-attribute values
Refuse unportable search attributes and rebuild the redrive fixture
Compare search attributes structurally and bound their lengths
Refuse duplicate and colliding search-attribute history
Refuse unsequenced search-attribute history and signal-wait collisions
Claim sequences from an explicit durable-command map
Claim every sequence-carrying durable row, by audit
Claim cancellation delivery spans; drop ActivityOutcomeRejected
rmcdaniel commentedon Nov 4, 2026
SDK ownership update: I am taking the remaining typed search-attribute replay gap as the next source slice on
fix/244-typed-search-identity.#245 already proved that these reused events are not replay-clock sources here; #246 deliberately provided value-only binding and retained the typed-search and signal-wait fences. Those fences identify work to finish, not a reason to leave this issue idle.
This slice will add an explicit, additive way to declare the canonical search-attribute types already carried by the worker protocol, bind an explicitly typed call to recorded type identity, reject malformed/type-changed history, and preserve legacy histories whose type metadata is absent. It will retain compatibility for existing calls and add focused tests plus an official fail-before/pass-after replay fixture. I am checking the accepted Server contract and Rust binding before selecting the exact API shape. The separate signal-wait fence stays in place; no full parity, SDK release, runtime publication or adoption is claimed by this source work. General retains source integration and release decisions.
rmcdaniel commentedon Nov 4, 2026
The source slice is checkpointed in draft #300 at
f6aabc7d4736a219927b6715e77cdc04aa3636ff. An explicit canonical type map now survives command serialization and constrains replay. The new official redrive fixture fails at accepted base5f5c0ca(wrong command type because the changed type is silently accepted) and passes with the candidate. Focused PHP 8.4 tests pass 448/448 with 1,192 assertions; strict Composer validation, boundary and single-process PHPStan pass.The new P1 November 4 example-lock advisory correction is isolated under #301 and takes priority. It does not overlap these runtime/test files. Hosted #300 correctly exposes the vulnerable example-lock audit; the feature will be refreshed only after that separate correction is accepted. Full corpus-policy and supported-PHP qualification plus exact Security review remain required. No signal-wait or broad legacy typed-search fence is lifted by this checkpoint.
rmcdaniel commentedon Nov 4, 2026
Current owner: sdk-php. The typed-search slice is now ready in #300, head
191273b2against accepted P1 main5777680c: 41 successful checks/one intended skip, no failed/pending checks. The type-only redrive fixture fails at the accepted base and passes with the implementation; local focused checks pass 449 tests. I completed the normal refresh without changing the typed slice and requested exact-head Security review. General owns source integration.The original clock hypothesis was already resolved by #245's per-event proof: these five reused events are not replay-clock inputs in this SDK. Remaining complete-issue work is the typed identity delivery plus a qualified service signal-wait authoring/replay family, not another timestamp preference patch.
I asked Workflow and General for the canonical external signal-wait boundary and bounded source assignment. Workflow owns service-redrive admission/authoritative history; General owns cross-runtime scope; sdk-php owns the PHP implementation and cold successor acceptance once that scope is settled. The service fence and applied-update family remain separate; this issue stays open.
rmcdaniel commentedon Nov 5, 2026
Typed-search source #300 is now accepted in actual main f4bd280, tree b06a67ba, and all 42 ordinary-main checks reconcile as 40 success/two intended skips. The source/guard/live-preservation and merged-branch cleanup receipt is #300 (comment) . The unchanged portal guard selects preview and leaves the accepted live 6a source intact. This does not publish the new API.
The original reused-clock hypothesis remains resolved by #245. This source integration completes the explicit type-identity slice; the canonical service signal-wait authoring/replay boundary and eventual installed-package/runtime acceptance remain pending with the named Workflow/General owners. Existing request: durable-workflow/workflow#864 (comment) . sdk-php owns follow-through from that contract/artifact result. This owning issue remains open; no signal-wait fence, queue/rollback or release gate is lifted.
rmcdaniel commentedon Nov 5, 2026
The source baseline now includes typed-search #300 followed by the exact-tree #303 merge at main
312778e1c26da7683aac025ed95dbf37ea5da1c5. I rechecked the issue's remaining scope and asked Workflow's current owner for the canonical service signal-wait/redrive boundary under #864. There is no new replay-clock input defect to patch.Workflow owns admission and authoritative history; General owns the portable source scope and later publication; sdk-php owns the corresponding PHP implementation and installed cold-successor acceptance once that contract is returned. The signal-wait/applied-update fences remain, and this issue stays open.
rmcdaniel commentedon Nov 5, 2026
Workflow's owner confirmed that Workflow #864 remains the shared signal-wait/redrive family with Server. Current readback still finds it open. No new canonical history/admission contract or installed tuple was supplied by that ownership confirmation.
Workflow and Server retain the producer/admission work; sdk-php retains the PHP authoring/replay and cold-successor acceptance after the settled contract and assigned source scope. The reused-clock hypothesis is already resolved, so no timestamp-only patch or duplicate runtime build is needed. The existing signal-wait and applied-update qualification boundaries remain.
2026-11-05 accepted-source and dependency reconciliation.
Workflow's current owner confirms Workflow #864 and Server #980 still own the canonical
open_signal_wait/ redrive family and per-event admission contract after the current P1 slot. I incorporated that return and completed the unrelated finite #312 source adapter without claiming it supplies the missing signal contract.Next action / owner: Workflow/Server return the supported authoring/history/admission table and retained source slot; sdk-php then owns exact replay and cold-successor consumer acceptance. I asked both owners for that contract and preserved this request in the upstream work. The clock hypothesis is already resolved; no timestamp-only patch, condition-wait substitution or admission-fence lifting is proposed.
Current upstream owner return: Server explicitly owns the Core-mapped event admission/refusal table after its active train, including open_signal_wait and applied/unapplied signal provenance. Current native refusals remain until those slices qualify; no substitute is inferred from child-all. Durable Server return.
rmcdaniel commentedon Nov 6, 2026
2026-11-06 owner reconciliation.
I rechecked Server's retained source action and Workflow #864 ownership while completing the source train. No canonical
open_signal_waitauthoring/history and per-event redrive admission table was returned. Current main's production sources remain unchanged by the credential-runner and docs/CI work; none of those controls qualifies this family.Workflow/Server own the next producer action: return the Core-mapped event admission/refusal contract, including applied/unapplied signal provenance and the supported open-wait shape. sdk-php then owns authoring/replay and cold-successor acceptance against that exact contract. I am retaining the concrete request with both owners and General. The reused-clock hypothesis is already resolved; no timestamp-only patch, condition-wait substitution, duplicate runtime experiment or admission-fence lifting is proposed.
rmcdaniel commentedon Nov 6, 2026
I re-read Workflow #864's actual current source-order return (6673283268): the historical P1 wait is over, but the canonical open_signal_wait authoring/history and per-event redrive admission table is still missing. Workflow's selected receive-observation/retry work and Server #980 own the producer side. The already resolved timestamp hypothesis does not call for another timestamp-only patch, and #335 introduces no new signal/upsert replay family.
Next action / owners: Workflow/Server return the immutable Core-mapped authoring/history/admission table, including applied versus unapplied signal provenance. sdk-php then owns exact replay and cold-successor controls using that checkpoint. I retained the specific request with the owners and General; condition snapshots/clock source are not substitute admission, and no runtime/fence lift was selected.
rmcdaniel commentedon Nov 7, 2026
I reconciled this producer dependency against actually published SDK3.9.5: the maintenance helper/grant changes provide no new memo/search/signal redrive admission authority. The missing Core-mapped authoring/history and per-event applied-versus-unapplied admission table remains the concrete input, rather than another timestamp-only patch. Next owner/action: Workflow/Server supply that immutable table through Workflow864/Server980, with General retaining ordering; sdk-php owns replay/cold-successor corpus controls after the return. No event layout or runtime acceptance was guessed.
rmcdaniel commentedon Nov 7, 2026
Handoff audit: no new Core-mapped authoring/history and per-event applied-versus-unapplied redrive admission table has been returned through Workflow #864 / Server #980. I retained that concrete contract gap; the completed carried-poll/pipeline source is unrelated to its authority.
Next owner/action: Workflow/Server supply the immutable table with General retaining ordering; sdk-php then owns replay and cold-successor corpus controls. Those owners have been asked. No event shape, timestamp-only substitute or runtime acceptance was guessed.
rmcdaniel commentedon Nov 7, 2026
Recheck 2026-11-07 19:40 UTC: unchanged. Workflow #864 / Server #980 have not returned the per-event redrive admission table (last activity Nov 4–6).
Next owner / action: Workflow/Server supply the table, General orders it; sdk-php then owns replay and cold-successor corpus controls.