Follow-up from #4904 / aao-release-bot review. Filed as a separate issue per the response comment.
Problem
In #4904 (3.1 additive-deprecate), both media_buy_status and the deprecated status \$ref the same media-buy-status.json enum on `CreateMediaBuySuccess` and `UpdateMediaBuySuccess`. A seller emitting divergent values — e.g., `status: "active", media_buy_status: "paused"` — passes JSON Schema validation today because both fields are independently valid against the enum. Nothing in the schema layer prevents this, and buyers parsing defensively as `response.media_buy_status ?? response.status` would see the new field's value while buyers still on the legacy access path would see the old.
This is an edge case (no good-faith seller will emit divergent values), but the deprecation window leaves the contract underspecified for the bad-faith / buggy case.
Options
A — schema-level if/then constraint (preferred for machine enforcement):
```json
{
"if": {
"properties": {
"status": { "type": "string" },
"media_buy_status": { "type": "string" }
},
"required": ["status", "media_buy_status"]
},
"then": {
"properties": {
"status": { "$ref": "#/properties/media_buy_status" }
}
}
}
```
Or equivalent — a sibling-equality constraint expressible in Draft-07 / 2020-12. Requires verifying the codegen toolchains can handle it (some json-schema-to-X tools quietly drop `if/then` blocks).
B — prose tightening (cheap, lower enforcement):
Add a MUST clause to the descriptions on both `status` and `media_buy_status`: "During the 3.1 deprecation window, sellers emitting both `media_buy_status` and the deprecated `status` MUST emit identical values. Divergent emission is a conformance violation and will be flagged by 3.1 compliance storyboards."
Plus a storyboard assertion that grabs both fields when present and asserts equality.
Recommendation
B for 3.1, since the migration window is short (#4906 removes the deprecated field in 3.2 — at which point this edge case disappears entirely). The cost of adding an `if/then` block, regenerating SDKs, and verifying every codegen toolchain isn't worth it for a transient ambiguity that resolves cleanly at the next minor.
If we land #4906 on a typical 3.2 cadence, this issue is effectively self-resolving. File for tracking but de-prioritize.
Related
Follow-up from #4904 / aao-release-bot review. Filed as a separate issue per the response comment.
Problem
In #4904 (3.1 additive-deprecate), both
media_buy_statusand the deprecatedstatus\$refthe samemedia-buy-status.jsonenum on `CreateMediaBuySuccess` and `UpdateMediaBuySuccess`. A seller emitting divergent values — e.g., `status: "active", media_buy_status: "paused"` — passes JSON Schema validation today because both fields are independently valid against the enum. Nothing in the schema layer prevents this, and buyers parsing defensively as `response.media_buy_status ?? response.status` would see the new field's value while buyers still on the legacy access path would see the old.This is an edge case (no good-faith seller will emit divergent values), but the deprecation window leaves the contract underspecified for the bad-faith / buggy case.
Options
A — schema-level if/then constraint (preferred for machine enforcement):
```json
{
"if": {
"properties": {
"status": { "type": "string" },
"media_buy_status": { "type": "string" }
},
"required": ["status", "media_buy_status"]
},
"then": {
"properties": {
"status": { "$ref": "#/properties/media_buy_status" }
}
}
}
```
Or equivalent — a sibling-equality constraint expressible in Draft-07 / 2020-12. Requires verifying the codegen toolchains can handle it (some json-schema-to-X tools quietly drop `if/then` blocks).
B — prose tightening (cheap, lower enforcement):
Add a MUST clause to the descriptions on both `status` and `media_buy_status`: "During the 3.1 deprecation window, sellers emitting both `media_buy_status` and the deprecated `status` MUST emit identical values. Divergent emission is a conformance violation and will be flagged by 3.1 compliance storyboards."
Plus a storyboard assertion that grabs both fields when present and asserts equality.
Recommendation
B for 3.1, since the migration window is short (#4906 removes the deprecated field in 3.2 — at which point this edge case disappears entirely). The cost of adding an `if/then` block, regenerating SDKs, and verifying every codegen toolchain isn't worth it for a transient ambiguity that resolves cleanly at the next minor.
If we land #4906 on a typical 3.2 cadence, this issue is effectively self-resolving. File for tracking but de-prioritize.
Related
statustomedia_buy_status(additive-deprecate, #4895) #4904 — the 3.1 additive-deprecatestatuson CreateMediaBuySuccess / UpdateMediaBuySuccess (3.2) #4906 — 3.2 removal of deprecated `status` (resolves this issue when shipped)statustomedia_buy_statuson get_media_buys / get_media_buy_delivery / core/media-buy #4905 — 4.0 nested cascade