Repository navigation
Route pinned runs by their recorded definition like PHP; run every fixture check before failing - #667
Merged
Merged
Conversation
Server 2.10.0's WorkflowDefinitionRouting decides at claim which worker may take a workflow task of a run whose start recorded its worker cohort's definition fingerprint. Native offered such tasks to any worker. Now a worker advertising the recorded fingerprint takes the task. A worker with another definition waits while an eligible peer has the recorded one, then takes it only if it advertises workflow_entry_arguments_validation. Workers without a fingerprint, or runs without a recorded one, get nothing. Eligible peers follow WorkflowReplayEligibility: fresh, on the run's queue and build, supporting the type, and able to replay its cooperative cancellation and metadata history. Registrations and heartbeats now record their protocol version under _worker_protocol_version in the process metrics, as PHP 2.10.0 does; worker listings show it.
Server 2.10.0 reports WorkflowDefinitionRouting's decision for a run's next due ready workflow task as definition_routing in describe, repair and debug (inspect), and samples a queue's ready runs in task queue describe (forQueue). Native now does the same: the recorded context, PHP's status, eligible worker counts by definition, up to ten example workers, blocked, runnable_task and PHP's resolution text. A blocked route is a debug warning (workflow_definition_routing_blocked, diagnostic_status needs_attention) and marks the queue's repair as needing attention.
The SQLite, PostgreSQL and MySQL fixture steps stopped as soon as native's record of the frozen corpus failed, which skipped every later check in the step: the SDK direction, patch, marker, range and restart profiles. One expected difference (native's Server 2.10.0 SignalRejected in signals-before-worker) therefore hid everything after it. The native record and the comparison now keep their status, the rest of the step runs, and the step fails at its end if either failed. Nothing about the expectations or the frozen artifacts changes.
12 tasks
The worker-fencing contract compares whole run reads across a live registration replacement. Native and Server 2.10.0 describe a run with definition_routing, which reports how the next ready workflow task would route now; releasing the lease makes that task runnable without changing the run or its history. The preservation checks now compare the reads without that block, and a unit case covers both a routing-only change and a real run change.
The SDK query contract compares the run read before and after a query. definition_routing reports how the next ready task would route now, so a worker leaving changes its counts without touching the run or its history.
|
This was referenced Oct 22, 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.
Part of #325. Two commits.
1. Workflow definition routing like Server 2.10.0
Native records the definition fingerprint a start's worker cohort agrees on, as PHP does. It then offered that run's workflow tasks to any worker. PHP routes them by the recorded definition (
WorkflowDefinitionRouting,WorkflowReplayEligibility). Native now does too:Claim (
forWorker). For a worker-pinned run:workflow_entry_arguments_validation;Eligible peers are fresh workers on the run's queue and build that support the type and can replay its cooperative-cancellation and metadata history. An unpinned run goes to any worker.
Protocol version. Registrations and heartbeats record it under
_worker_protocol_versionin the process metrics, as PHP 2.10.0 does. Worker listings show it.Reports (
inspect,forQueue).definition_routing, with PHP's status, counts, example workers,blocked,runnable_taskand resolution.workflow_definition_routing_blocked,needs_attention).The gap-list entry is removed. Checkpoint:
docs/rust-server-port-checkpoints/2026-10-22-definition-routing.md.2. Fixture steps run every check
The SQLite, PostgreSQL and MySQL fixture steps stopped as soon as native's record of the frozen corpus failed. That skipped every later check in the step: the SDK direction, patch, marker, range and restart profiles.
Since #663, the record names every difference, and there is one: the expected
signals-before-worker(cloud discussion 418). That one difference hid all the later checks. The native record and the comparison now keep their status, the rest of each step runs, and the step fails at its end if either failed. Expectations and frozen artifacts are unchanged.Tests
definition_routing.rs: routing to the recorded definition, entry-validating replacements, unpinned runs, protocol metrics, and the four reports. The worker listing test now expects the protocol key.This PR will be merged by hand once all checks, including the Rust suites, pass.