Batch operation "feature" scenarios generated with empty filter bodies

Symptoms

Component: path-analyser (request body synthesis)
Severity: High — affects all batch operation endpoints across every generated feature scenario
Every feature-1 (base) scenario for batch operation endpoints fails immediately:

Response body: {"type":"about:blank","title":"INVALID_ARGUMENT","status":400,
"detail":"At least one of filter criteria is required.",
"instance":"/v2/process-instances/cancellation"}

Affected operations (not exhaustive):

• cancelBatchOperation.feature
• cancelProcessInstancesBatchOperation.feature
• deleteDecisionInstancesBatchOperation.feature
• deleteProcessInstancesBatchOperation.feature
• resolveIncidentsBatchOperation.feature
• migrateProcessInstancesBatchOperation.feature
• modifyProcessInstancesBatchOperation.feature
• suspendBatchOperation.feature
• resumeBatchOperation.feature

Root Cause Analysis

The path-analyser synthesizes the "base" positive scenario by populating the request body with default or inferred values for each field. For batch operations the request body contains a filter object whose properties are all optional individually, but the API contract requires at least one of them to be set.

Because every individual filter property is optional in the OpenAPI spec, the planner treats the whole filter object as safely omittable and emits an empty {} or omits the filter entirely. The server-side validation rejects this with INVALID_ARGUMENT.

This is a known OpenAPI modelling pattern ("at least one of N optional fields is required") that cannot be expressed with standard required arrays and is typically conveyed only in prose. The planner has no mechanism to detect or honour this constraint.

Cascading impact: the batchOperationKey that subsequent tests need (e.g. getBatchOperation, cancelBatchOperation, resumeBatchOperation) is never extracted, causing those downstream tests to also fail.

Solution Proposal (from AI :)

Short-term

Add an entry to configs/camunda-oca/domain-semantics.json (or a dedicated request-defaults.json override) for each batch operation endpoint that populates a minimal valid filter. Example:

{
  "operationId": "cancelProcessInstancesBatchOperation",
  "requestBodyDefaults": {
    "filter": {
      "state": "ACTIVE"
    }
  }
}

Long-term

Extend the path-analyser's body-synthesis pass to recognise x-at-least-one or equivalent vendor extensions on the OpenAPI schema and generate at least one discriminator field when the extension is present. Alternatively, introduce a "body invariant" annotation in domain-semantics.json that the planner checks before finalising the request body.

Start by tracing the path-analyser body-synthesis pass and inspect configs/camunda-oca/domain-semantics.json for existing request defaults. Reproduce an affected batch-operation feature scenario, then verify that generated requests contain a valid filter and that downstream batchOperationKey extraction succeeds across the listed operations.