DOCUMENTATION / RULE REFERENCE
Request property removed, server strictness unknown.
By Soumik Ghosh ยท Published
A removed request field can be tolerated or rejected by the server. Without an established unknown-field policy, ParityDiff leaves the classification ambiguous.
- Rule ID
request.removed_unknown_strictness- Direction
- request
- Classification
- Needs review
What does a minimal example look like?
These are illustrative JSON Schemas for the changed constraint, not a captured vendor release. The rule ID applies to detector findings with the relevant direction and policy context.
Before
{
"type": "object",
"properties": {
"name": {
"type": "string"
}
}
}After
{
"type": "object",
"properties": {}
}What should I check in my application?
Find the operation and affected field in the scanned commit. Confirm the server policy and application intent, inspect any missing coverage, then test the complete candidate. This rule alone does not prove repository impact, runtime failure, or a safe automatic fix.
Replay classifier inputs and policy choices or compare these schemas in both directions.
API compatibility guides and tools
- oasdiff and API code impact analysis answer different questions.
- Detect breaking API changes in a GitHub workflow.
- Why a TypeScript build can pass after an API changes.
- OpenAI OpenAPI breaking changes: a captured response change.
- Sentry OpenAPI breaking changes: removed replay query values.
- Inspect classification rules interactively
- Compare JSON Schemas
- Plan your business evaluation
Rule reference
request.enum_removed: Request enum value removedrequest.now_required: Request property becomes requiredresponse.removed: Response property removedresponse.now_optional_or_nullable: Response property becomes optional or nullablerequest.removed_unknown_strictness: Request property removed, server strictness unknown