Files
orca/docs/reference
Jinwoo-H e442e4fa55 test: pair orchestration federation against the two newest releases
#19689 shipped because no lane paired two builds over `orchestration.*`. The
cross-version harness only covered the terminal stream and `agentSession.*`, and
every federation "old peer" test wrote a protocol_version integer into a row and
read it back with the same build, so a coordinator that omits a field and a host
that starts requiring it were both invisible.

Pairing against the newest tag alone would not have caught it either: the newest
tag already contains the fix for anything broken and repaired inside the last
release cycle. A worker host and the desktop that dispatches to it update on
their own schedules, so N-1 is an ordinary peer. The suite therefore extracts the
two newest stable tags and runs both skew directions against each.

Each pairing drives one journey through the real coordinator modules —
`startFederatedWorker` composes the attach params, `syncFederatedDispatch` drives
the relay — against the peer build's real dispatcher over its real store, with a
JSON round trip so an `undefined` field drops exactly as on the wire. What the old
side has is read from its checkout; nothing about a release is written down.

`pr-code-change-scope.mjs` did not route orchestration source at this job, so the
lane would not have run on the PR that broke it; the federation source prefixes
are added with cases in its test. The job's file list is now derived from the
directory, so a new suite that is never named in the workflow fails instead of
covering nothing.
2026-09-09 19:40:38 -04:00
..