Tracking issue for the 3.2 removal half of #4895's additive-deprecate.
What 3.1 (PR #4904) did
Strictly additive on create_media_buy and update_media_buy success responses:
- Added
media_buy_status: \$ref media-buy-status.json alongside existing top-level `status`.
- Marked legacy top-level `status` as `deprecated: true` (description-level).
- Compliance storyboards already assert `path: "media_buy_status"` — 3.1-conformant sellers MUST emit the new field; legacy `status` is schema-valid but fails storyboard certification.
What 3.2 needs to finish
Remove the deprecated top-level `status: MediaBuyStatus` from `CreateMediaBuySuccess` and `UpdateMediaBuySuccess`.
- `static/schemas/source/media-buy/create-media-buy-response.json` `CreateMediaBuySuccess` branch: delete the deprecated `status` property entry.
- `static/schemas/source/media-buy/update-media-buy-response.json` `UpdateMediaBuySuccess` branch: same.
- After 3.2, top-level `status` on these two responses unambiguously carries envelope TaskStatus only.
Why 3.2, not 4.0
The protocol-expert recommendation (split from the original #4905 bundle):
The deprecation window is the point; longer just means more SDK types carry both fields. Adopters who upgrade to 3.2 will already have moved off the legacy form because storyboards force it in 3.1.
Two rename boundaries (3.2 + 4.0) is a cost, but carrying a deprecated field for 12+ months across every SDK release is a bigger one. The storyboard gate in 3.1 already does the migration enforcement work.
Adopter impact
- Sellers (3.2+): MUST emit `media_buy_status` on create/update success responses. The legacy `status` is no longer schema-valid on these surfaces.
- Buyers (3.2+): `media_buy_status` is the only field carrying MediaBuyStatus on the create/update response root. Code reading `response.status` on these surfaces now receives the envelope TaskStatus (or undefined for the create/update payload branch).
- 3.1 → 3.2 migration: for sellers, mechanical — remove the legacy `status` emission, keep `media_buy_status`. For buyers, audit any `response.status` access on create/update success and switch to `response.media_buy_status`.
Downstream
- `@adcp/client` (TypeScript SDK): regen against 3.2 schemas. The `@deprecated`-marked `status` field disappears from `CreateMediaBuySuccess` / `UpdateMediaBuySuccess` types. Buyer code reading `.status` on these resolves to envelope TaskStatus only.
- `adcp` (Python SDK): same.
- `adcp-go`: same.
- Compliance storyboards: already assert `path: "media_buy_status"`. No storyboard changes needed for the removal.
What stays for 4.0 (#4905)
The nested `status` cascade on `get-media-buys-response` items, `get-media-buy-delivery-response` items, and `core/media-buy.json` is not in this issue's scope — that's a genuinely-breaking `required[]` swap held for the 4.0 major. See #4905.
Related
Tracking issue for the 3.2 removal half of #4895's additive-deprecate.
What 3.1 (PR #4904) did
Strictly additive on
create_media_buyandupdate_media_buysuccess responses:media_buy_status: \$ref media-buy-status.jsonalongside existing top-level `status`.What 3.2 needs to finish
Remove the deprecated top-level `status: MediaBuyStatus` from `CreateMediaBuySuccess` and `UpdateMediaBuySuccess`.
Why 3.2, not 4.0
The protocol-expert recommendation (split from the original #4905 bundle):
Two rename boundaries (3.2 + 4.0) is a cost, but carrying a deprecated field for 12+ months across every SDK release is a bigger one. The storyboard gate in 3.1 already does the migration enforcement work.
Adopter impact
Downstream
What stays for 4.0 (#4905)
The nested `status` cascade on `get-media-buys-response` items, `get-media-buy-delivery-response` items, and `core/media-buy.json` is not in this issue's scope — that's a genuinely-breaking `required[]` swap held for the 4.0 major. See #4905.
Related
status(TaskStatus) collides with payloadstatus(MediaBuyStatus) at the same top-level key on create/update/cancel_media_buy #4895 — driver issue (3.1 additive-deprecate)statustomedia_buy_status(additive-deprecate, #4895) #4904 — the 3.1 additive-deprecate landing PRstatustomedia_buy_statuson get_media_buys / get_media_buy_delivery / core/media-buy #4905 — 4.0 nested cascade (separate scope)statuson every task response envelope (closes #4832) #4876 — envelope status REQUIRED (beta.2)