Fix sdkdev integration failures: gate REGION_DURABLE, cover DURABLE, pin OSS image

[chrishagglund-ship-it]

What's failing

Four tests in WorkflowExecutor.test.ts have been red on integration v5 sdkdev
(shard 1/3, all of Node 20/22/24):

● Should execute complex workflow with DURABLE + TARGET_WORKFLOW
  [Conductor SDK Error]: Failed to execute workflow:
  REGION_DURABLE consistency requested but region replication is not
  enabled/configured on this node

Note the mismatch: the test says DURABLE, the server says REGION_DURABLE.

Why

The cases were named DURABLE + * but had always passed
Consistency.REGION_DURABLE — the section comment even said
// REGION_DURABLE consistency tests. Nothing in this repo changed. They went red
when sdkdev picked up a server build carrying the active/active work
(ea0a37ad74, "region-durable
workflow start (synchronous cross-region push, fail-closed)").

Before that change, REGION_DURABLE was an inert enum value that fell through the
same scheduleWorkflow branch as DURABLE, so the flag was accepted and silently
ignored. After it, a node with no replicator wired rejects the start outright rather
than appearing to honour a guarantee it cannot provide.

The server is right. sdkdev is a single-node instance that is not meant to have
replication. The tests were green under false pretences: they asked for cross-region
durability, got a plain local start, and asserted success.

java-sdk hit this identically and fixed it in
java-sdk#167, which dates
the sdkdev upgrade precisely — 2026-08-11, orkes-conductor 5.3.0 → 5.5.0.

Changes

1. Gate the REGION_DURABLE cases — renamed to REGION_DURABLE + * to match what
they actually request, gated behind CONDUCTOR_REGION_DURABLE_ENABLED via a new
testForRegionDurable helper.

Explicit opt-in rather than catch-the-500-and-skip, following java-sdk's reasoning:
auto-skip would restore exactly the silent green that hid this for months, and would
mask a genuine replication regression on a cluster where it is meant to work. Same
env var name as java-sdk so both SDKs configure identically.

2. Add four real DURABLE + * cases. Consistency.DURABLE appeared nowhere
in the suite despite being the default level, and it takes a different executor path
than SYNCHRONOUS:

Consistency	Executor path
SYNCHRONOUS	decideWithLock + pushToDeciderQueueWithTimeout, inline
DURABLE	scheduleWorkflow — async decider queue

Less new coverage than restored coverage — it is what the REGION_DURABLE cases were
really exercising all along, back when the server ignored the flag.

3. Write the OSS Conductor image tag in exactly one place. Previously the OSS job
tracked latest, so an upstream release could turn it red on an unrelated PR — the
same class of surprise as the sdkdev upgrade above. The tag now resolves like this:

Context	Tag comes from
CI, normal run	E2E_TEST_OSS_CONDUCTOR_VERSION org variable, or the workflow_dispatch input
CI, fork PR	the image: default in scripts/docker-compose-oss.yaml — GitHub withholds vars.* from forks exactly as it withholds secrets
Local	the same compose default, unless run-integration-oss.sh --version <tag> overrides it
CI, non-fork run with no org variable	nothing — the preflight step fails with an actionable message

The default itself is written once, on the image: line of the compose file
(3.32.3). run-integration-oss.sh applies no default of its own and exports
OSS_CONDUCTOR_VERSION only when --version actually supplied one, so a plain local
run and a fork CI run reach the identical image by the identical path — which is what
lets the script reproduce a CI failure. This removed a hardcoded fallback rather than
adding a mechanism.

4. Pull the image in CI before starting the stack. Redundant on a GitHub-hosted
runner, whose VM is ephemeral and starts with no cached copy, so up pulls anyway.
Kept regardless: it costs no extra network pull (up then finds the image locally),
it splits "couldn't pull the image" from "the stack didn't come up" into two distinct
red steps, and it is what stops a mutable tag going stale if this job ever moves to a
self-hosted runner with a warm Docker daemon — the same reason the local script pulls.
It also logs the tag actually in use, which now matters because a fork PR's tag is not
spelled out in the workflow.

Test matrix after this change

Cases	Consistency	Gated
SYNC + * ×4	SYNCHRONOUS	no (unchanged)
DURABLE + * ×4	DURABLE	no — new
REGION_DURABLE + * ×4	REGION_DURABLE	yes

sdkdev goes from 4 failures → 4 skips + 4 new passing cases.

Review feedback

All three comments are addressed in 5227051:

Comment	Resolution
CI pins the image tag but a local run defaults to latest, so the script won't reproduce a CI failure	Change 3 — one default, written in the compose file, reached by both paths
The script pulls the image before starting the stack, but CI doesn't	Change 4 — new Pull Conductor OSS image step
agent-e2e.yml already calls this CONDUCTOR_OSS_VERSION — use one name, or say why they're separate	Comment added at the definition in agent-e2e.yml. They are separate on purpose: that one is a Maven Central artifact version for the conductor-server boot JAR, this one a Docker Hub image tag. The two registries publish different version sets — Maven has no latest — and the agent suites carry a floor this job does not (≥ 3.32.0-rc.8, for the /agent/* control plane and TaskDef.runtimeMetadata persistence). Converging them is possible once the org variable holds a concrete version, but that is a rename plus a bump of a stale pin, not this PR.

Notes for reviewers

• No CI configuration needs CONDUCTOR_REGION_DURABLE_ENABLED. Gated-off is the
  correct state for a single-region server; java-sdk likewise sets it in no workflow.
  Set it only against a target with cross-region replication configured.
• E2E_TEST_OSS_CONDUCTOR_VERSION is currently set to latest at the org level.
  So the pin in change 3 is nominal for normal CI runs until someone sets that variable
  to a real version — today it is the compose default that actually holds the line, on
  fork PRs and locally. The variable must also have this repo in its repository access
  policy, or a non-fork run fails the preflight step by design.
• Known, pre-existing, untouched: on a waitForSeconds timeout the execute endpoint
  returns toWorkflowRun(...), which never sets responseType — so a timeout surfaces
  as a confusing undefined mismatch rather than "it timed out." Affects all 12 combos
  equally and predates this PR; worth a separate fix.

[ambiorix2099]

LGTM. Approved with comments.