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.featurecancelProcessInstancesBatchOperation.featuredeleteDecisionInstancesBatchOperation.featuredeleteProcessInstancesBatchOperation.featureresolveIncidentsBatchOperation.featuremigrateProcessInstancesBatchOperation.featuremodifyProcessInstancesBatchOperation.featuresuspendBatchOperation.featureresumeBatchOperation.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.
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:Affected operations (not exhaustive):
cancelBatchOperation.featurecancelProcessInstancesBatchOperation.featuredeleteDecisionInstancesBatchOperation.featuredeleteProcessInstancesBatchOperation.featureresolveIncidentsBatchOperation.featuremigrateProcessInstancesBatchOperation.featuremodifyProcessInstancesBatchOperation.featuresuspendBatchOperation.featureresumeBatchOperation.featureRoot Cause Analysis
The
path-analysersynthesizes the "base" positive scenario by populating the request body with default or inferred values for each field. For batch operations the request body contains afilterobject 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 withINVALID_ARGUMENT.This is a known OpenAPI modelling pattern ("at least one of N optional fields is required") that cannot be expressed with standard
requiredarrays and is typically conveyed only in prose. The planner has no mechanism to detect or honour this constraint.Cascading impact: the
batchOperationKeythat 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 dedicatedrequest-defaults.jsonoverride) 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-oneor 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 indomain-semantics.jsonthat the planner checks before finalising the request body.