test: second topology e2e leg cannot pass for multi-orchestration topologies (shared Web Modeler, no per-leg cluster selection)

[eamonnmoloney]

Problem

For a topology with more than one orchestration release, the topology e2e phase runs one leg per
orchestration release. The second leg cannot pass, because process data is created through a
single shared Web Modeler that deploys to one cluster, while each leg asserts against its own
cluster's Operate and Tasklist.

Observed on multinamespace-2orch (mns2) on GKE, chart 8.10. All three releases deployed
successfully; both e2e legs failed:

leg	passed	failed	skipped	duration
orcha	16	3	5	18.9m
orchb	7	12	4	27.4m

Leg 2's failures are overwhelmingly data-visibility, not UI:

View Process Instance in Operate, assert it completes and assert result expression
Complete User Task in Tasklist & assert process complete in Operate
Navigate to Tasklist and Make Sure that the Two Deployed Processes Are Accessible
View Process Instance in Operate and complete User Task in Tasklist
Assert Diagram Has Successfully Completed in Operate
Ensure Modeler is not Accessible
… 13 in total

with 314 occurrences of not found in table, and one instance retried for 610s across 21 attempts
before giving up.

Root cause

The Hub's Web Modeler has both orchestration clusters registered:

$ kubectl -n <hub-ns> exec pod/postgresql-… -- \
    psql -d webmodeler -t -A -c 'SELECT name FROM clusters ORDER BY name'
Orchestration A
Orchestration B
hub

The suite has no way to select a cluster per leg. It creates its fixture processes through Modeler,
which deploys to whichever cluster it resolves, so only the leg whose cluster happens to match can
observe its own data. The other leg queries an Operate that never received the records — hence
not found in table rather than an assertion or timing failure.

Ensure Modeler is not Accessible failing fits the same picture: that test's assumption does not hold
when one Modeler is shared across clusters reached on different hosts.

Scope

This is a property of the suite, not of any chart change. It is the same class of gap as the suite not
being Physical-Tenant aware: it is not cluster-aware either, because
global.topology.clusters[].components.orchestration is singular and the suite resolves apps against
a single baseURL plus per-app context paths.

Attribution note: this surfaced while validating an unrelated values change. That change renders the
affected releases byte-identically, and the Camunda exporter feeding Operate reads
orchestration.index.prefix, which it does not touch.

Options

1. Run a single e2e leg for multi-orchestration topologies. Cheapest, and honest about the
   coverage boundary: one cluster gets exercised, the rest get deploy-only verification. Worth a
   comment in the scenario file so the next reader knows why.
2. Teach the suite to target a named cluster per leg, e.g. a CLUSTER_NAME env var the Modeler
   deployment step honours. Correct fix, but it is a change in
   c8-cross-component-e2e-tests plus an npm release, so cross-repo.

Until one of these lands, enabling two legs for a multi-orchestration topology enables a leg that
cannot pass, which reads as a product failure when it is a harness limitation.

[distro-ci]

🧭 Triage Assessment

Field	Value
Work type	TASK
Kind	internal
Severity	⚠️ Mid
Likelihood	🔥 High
Confidence	0.95

📝 Rationale

Within SM Platform Distribution scope because the team boundaries assign ownership of Helm Charts, camunda-platform-helm, and automated scenario testing/deployments to Distribution. This is a TASK, not a BUG: the chart and product behavior are not incorrect; the internal E2E harness lacks topology-aware cluster selection. The requested work is a discrete internal CI reliability improvement, matching the precedent for multi-namespace CI coverage. kind=internal is the best fit because the change improves non-customer-facing test infrastructure rather than product behavior, documentation, or a new customer capability. Severity is mid because it blocks reliable validation of a multi-orchestration scenario but has a clear workaround—run one leg—and no customer production outage or data-loss impact. Likelihood is high because the failure is deterministic whenever the two-leg topology is enabled. The issue is sufficiently specified with reproduction evidence, root cause, scope, and concrete options, so missing information is false. A strict duplicate was not found. Related issue #6651 covers broader multi-orchestration support and CI coverage, while #4915 is the earlier multi-namespace CI coverage issue; #6308 is a broader 8.10 testing-gap umbrella. Additionally, the proposed upstream fix appears to have already landed in c8-cross-component-e2e-tests PR #2884, which adds named Modeler cluster selection and validates both orchestration legs; the issue should therefore be linked to that change or closed as resolved if confirmed.

🔍 Similar Issues

#6651, #4915, #6308

---

🤖 This issue was automatically triaged by an AI-based system.
✋ If you believe this assessment is incorrect, update the labels or add the triage:manual label for human review.