Variant scenarios inject tenantId parameters when multi-tenancy is disabled

Symptoms

Component: path-analyser (variant / path scenario planning)
Severity: High — affects all "path 1" variants for deployment-related and messaging operations

All variant tests that exercise a tenantId-parameterised code path fail at the first step:

Error: [deploy http://localhost:8080/v2/deployments] expected HTTP 200, got 400:
{"type":"about:blank","title":"INVALID_ARGUMENT","status":400,
"detail":"Expected to handle request Deploy Resources with tenant identifier
'tenantIdVar-jvwt7z', but multi-tenancy is disabled",
"instance":"/v2/deployments"}

Affected operations (not exhaustive):

• createDeployment.variant (path 1)
• activateJobs.variant (path 1)
• evaluateDecision.variant (dmn 1)
• createProcessInstance.variant (bpmn 1)
• broadcastSignal.variant (path 1)
• getProcessDefinitionInstanceVersionStatistics.variant (bpmn 1)
• All operations whose OpenAPI spec includes tenantId as an optional body/query parameter

---

Root Cause Analysis

The path-analyser discovers all optional parameters (including tenantId) and generates additional "path" variants that exercise each optional field with a synthesised value (e.g. 'tenantIdVar-jvwt7z').

There is an existing mechanism in configs/camunda-oca/ontology/global-context-seeds.json that correctly prevents tenantId from being auto-seeded in the base scenario:

{
  "binding": "tenantIdVar",
  "omitWhenUnbound": true,
  "rationale": "Camunda single-tenant mode default — the materializer must NOT
  auto-seed tenantIdVar from the universal prologue. When no step seeds it,
  ctx['tenantIdVar'] stays undefined and the consuming request omits the
  tenantId field (#342)."
}

This correctly handles the base scenario and any scenario where tenantId is not explicitly required. However, the path-analyser still generates variant scenarios that explicitly exercise the tenantId code path — these variants intentionally seed tenantIdVar with a unique synthetic value (e.g. tenantIdVar-jvwt7z) to cover the optional-field path. Those variants fail because multi-tenancy is disabled at the Zeebe broker level on the OCA test environment.

The global-context-seeds.json mechanism only suppresses auto-seeding; it does not prevent the path-analyser from generating variants that actively set tenantIdVar via the optional-path exploration pass.

---

Solution Proposal

Short-term

Add tenantId to a blocklist in configs/camunda-oca/filter-providers.json (or a new skip-variant-fields.json config) so the path-analyser does not generate variants for this field for the OCA config. A second config (camunda-hub) can choose to include it once multi-tenancy is configured.

Example addition to filter-providers.json for OCA:

{
  "field": "tenantId",
  "provider": "skip"
}

Long-term

Introduce a capability flag in configs/<config>/domain-semantics.json ("multiTenancyEnabled": false) that the planner reads before including tenantId in any variant path. When false, all tenantId parameters are excluded from variant generation and from request bodies in all scenarios.

---

Affected Files

• configs/camunda-oca/filter-providers.json
• configs/camunda-oca/domain-semantics.json
• path-analyser/src/ (variant path planning)
• All generated/camunda-oca/playwright/*.variant.spec.ts that include tenantId

Start with the variant path-planning code under path-analyser/src/ and compare it with configs/camunda-oca/filter-providers.json, domain-semantics.json, and global-context-seeds.json. Inspect affected generated/camunda-oca/playwright/*.variant.spec.ts files to confirm how tenantId variants are produced. Done means OCA variant scenarios no longer inject tenantId while base scenarios and configurations that support multi-tenancy retain their intended behavior.