CCOR-13193 - run integration(e2e) tests against latest oss conductor + v4 server

[chrishagglund-ship-it]

In this PR:

• oss latest in a small docker stack in the runner
• matrix to test against v4 and v5 for the two sets of integration tests
• fix for missing test fixture
• correct misshapen data structures

regarding the correction of misshapen data structures, it is technically a breaking change, and there is a question then of if this should be bugfix (eg 1.2.1) or major version (2.0.0). I lean towards the "type was impossible/useless" bugfix camp.

Breaking change: WorkflowTask.OnStateChange model corrected to match server contract

What breaks

Conductor.Client.Models.WorkflowTask.OnStateChange changes type:

• Before: Dictionary<string, StateChangeConfig>
• After: Dictionary<string, List<StateChangeEvent>>

Consequences for callers:

• The OnStateChange property and the WorkflowTask(...) constructor's onStateChange
  parameter change type (source-breaking at compile time).
• StateChangeConfig and the StateChangeEventType enum are removed.
• StateChangeEvent moves from the global namespace into Conductor.Client.Models
  (callers now need using Conductor.Client.Models;).

This surfaces on any call that sends or receives a WorkflowDef containing tasks with
onStateChange, e.g. MetadataResourceApi.UpdateWorkflowDefinitions(...)
(PUT /metadata/workflow) and MetadataResourceApi.Get(...) (GET /metadata/workflow/{name}).

Why the old type was wrong

onStateChange is serialized as part of WorkflowDef over the metadata REST API. The
authoritative server model is Map<String, List<StateChangeEvent>>, where the map key is
the event name (onStart, onSuccess, …) and each StateChangeEvent is { type, payload }:

• OSS: conductor/.../common/metadata/workflow/WorkflowTask.java:158 (field),
  StateChangeEvent.java:25-32
• Orkes: orkes-conductor/failover/conductor/.../common/metadata/workflow/WorkflowTask.java:158,
  StateChangeEvent.java:25-32 (identical; Orkes reuses the OSS common model)

There is no StateChangeConfig type anywhere on the server side.

So the server wants:

"onStateChange": { "onStart": [ { "type": "...", "payload": {...} } ] }

The old C# StateChangeConfig produced:

"onStateChange": { "": { "type": ["onStart"], "events": [...] } }

That's wrong on both read and write — wrong key (empty string instead of the event name)
and wrong value shape (a wrapper object with type/events instead of a bare list of
events). It only ever "worked" because nothing round-tripped it against a server that
enforced the shape. The new Dictionary<string, List<StateChangeEvent>> is an exact match
to the server model.

So: bug fix, or breaking change?

Both. The type was never correct, so this is fundamentally a bug fix — but because it
changes a public type, it's source-breaking. Flagging for the team to decide how to ship:

• Major version bump (treat strictly as a breaking change), or
• Minor/patch as a bugfix (argument: the old shape never produced valid requests, so no
  correct code could have depended on it), or
• Gate the new shape behind a feature flag / opt-in if we want a migration window.

The PR author favors minor/patch bugfix 🙂

[codecov]

Codecov Report

❌ Patch coverage is 72.72727% with 6 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
Conductor/Api/EnvironmentResourceApi.cs	40.00%	6 Missing ⚠️

Flag	Coverage Δ
unittests	3.69% <72.72%> (+0.37%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
Conductor/Client/Models/EnvironmentVariable.cs	100.00% <100.00%> (ø)
Conductor/Client/Models/StateChangeEvent.cs	100.00% <100.00%> (ø)
Conductor/Client/Models/WorkflowTask.cs	19.00% <100.00%> (+19.00%)	⬆️
Conductor/Api/EnvironmentResourceApi.cs	1.34% <40.00%> (+1.34%)	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[nthmost-orkes]

Good PR overall. Verified against server source and our capabilities catalog — the onStateChange fix and the OSS CI job are both the right moves. A few things worth discussing:

onStateChange type fix — verified correct, ship as bugfix

Confirmed against WorkflowTask.java:158 in conductor-oss/conductor:

private @Valid Map<String, List<StateChangeEvent>> onStateChange = new HashMap<>();

And StateChangeEvent.java has exactly { String type, Map<String, Object> payload } — no StateChangeConfig anywhere on the server side. The old C# type was never correct; no valid server response could have round-tripped through it. +1 for minor/patch bugfix versioning.

OSS CI job

The new integration_tests_oss job is the right approach. One thing: conductoross/conductor:latest will silently break if the server ships something the SDK doesn't handle yet. Consider pinning to a specific version (e.g. conductoross/conductor:3.32.0-rc.9 or the latest stable) so CI failures are deliberate rather than surprise. Even a comment above the image line noting the intended version would help.

Scheduler exclusion — possibly too conservative

Feature!=OSSSchedulerWIP excludes SchedulerTests from the OSS run. We've been building a capabilities catalog for the OSS server, and the scheduler is fully implemented in OSS 3.32.0-rc.9 with complete Flyway migrations for SQLite, MySQL, and PostgreSQL backends. The exclusion may be warranted if the tests use Orkes-specific API paths or auth-gated endpoints, but it's worth a quick check — the OSS scheduler surface should cover the basics that the integration tests exercise.

If the tests fail against OSS because of missing endpoints (e.g. a scheduler search API that only exists in Orkes Enterprise), documenting that in the OSSSchedulerWIP annotation or a comment in the test class would help the next person know why it's excluded.

Missed opportunity while touching WorkflowTask

Since this PR changes WorkflowTask.OnStateChange, it's a natural place to address WorkflowTaskTypeEnum gaps we found in our SDK audit (#161). The enum currently ends at WAITFORWEBHOOK = 30 and is missing NOOP, AGENT, GET_AGENT_CARD, and CANCEL_AGENT. Not a blocker for this PR, but worth a follow-up issue if there isn't one already.

The rest of the changes (EnvironmentVariable model, EnvironmentResourceApi deserialization fix, v4 matrix) look correct. The new tests in EnvironmentAndStateChangeModelTests cover the new type shapes cleanly.

[nthmost-orkes]

let's ship it, we can fix anything that comes up.