Summary
In the coverage phase, a case generated by the unexpected additional properties mutation can simultaneously carry known fields whose values violate the declared schema bounds (minimum/maximum, int64 range, minLength). The composed body is therefore NOT schema-compliant, yet the case is classified as a positive test — a correct 400 rejection is then flagged as a positive_data_acceptance failure ("API rejected schema-compliant request").
Version: schemathesis 4.21.10 (CLI, pip), observed against a live OpenAPI 3.1 service.
Example 1
Declared schema (verified live at run time):
"ScheduleRequest": {
"positionMs": {"type": "integer", "format": "int64", "minimum": 0, "maximum": 9223372036854775807},
"expected_epoch": {"type": "integer", "format": "int64", "minimum": 0, "maximum": 9223372036854775807}
}Reported failure:
POST /v1/groups/{groupId}/schedule
- API rejected schema-compliant request
Hint: The request body contains 3 additional properties not defined in the schema …
Body: {"action": "", "expected_epoch": -381, "positionMs": -17423081106881605632, …junk extra props…}
positionMs = -1.74e19 violates both minimum: 0 and the int64 range; expected_epoch: -381 violates minimum: 0. The 400 is a correct rejection of an invalid payload, not a positive-data acceptance failure.
Example 2 (same shape, different constraint kind)
POST /v1/groups and POST /v1/me/devices/{sessionId}/transfer were flagged positive_data_acceptance with the extra-properties Hint, while the composed bodies also violated declared minLength: 1 on name/toDeviceId (server answered a clean RFC7807 400: "Invalid request data" / "toDeviceId required").
Expected
A coverage case whose known fields violate declared constraints should be classified as a negative test (400 = pass), regardless of the additional-properties mutation it was composed with — or the composition should re-validate that the mutated body still satisfies the declared constraints for all known fields before classifying the case positive.
Notes
Related but distinct from #3155 (single out-of-bounds value in coverage phase): here the mis-classification arises specifically from the composition of the additional-properties mutation with per-field negative values.
Summary
In the coverage phase, a case generated by the unexpected additional properties mutation can simultaneously carry known fields whose values violate the declared schema bounds (
minimum/maximum, int64 range,minLength). The composed body is therefore NOT schema-compliant, yet the case is classified as a positive test — a correct400rejection is then flagged as apositive_data_acceptancefailure ("API rejected schema-compliant request").Version: schemathesis 4.21.10 (CLI, pip), observed against a live OpenAPI 3.1 service.
Example 1
Declared schema (verified live at run time):
Reported failure:
positionMs = -1.74e19violates bothminimum: 0and the int64 range;expected_epoch: -381violatesminimum: 0. The 400 is a correct rejection of an invalid payload, not a positive-data acceptance failure.Example 2 (same shape, different constraint kind)
POST /v1/groupsandPOST /v1/me/devices/{sessionId}/transferwere flaggedpositive_data_acceptancewith the extra-properties Hint, while the composed bodies also violated declaredminLength: 1onname/toDeviceId(server answered a clean RFC7807 400: "Invalid request data" / "toDeviceId required").Expected
A coverage case whose known fields violate declared constraints should be classified as a negative test (400 = pass), regardless of the additional-properties mutation it was composed with — or the composition should re-validate that the mutated body still satisfies the declared constraints for all known fields before classifying the case positive.
Notes
Related but distinct from #3155 (single out-of-bounds value in coverage phase): here the mis-classification arises specifically from the composition of the additional-properties mutation with per-field negative values.