Filed in response to adcontextprotocol/adcp#4904 (the 3.1 additive-deprecate on `CreateMediaBuySuccess` / `UpdateMediaBuySuccess` body-level `status`). The expert review on that PR flagged that JSON Schema `deprecated: true` propagation through Go codegen tools is often not propagated at all (`quicktype` and similar drop it).
What's needed
Either:
-
A unit test that asserts a deprecation surface — typically a `// Deprecated:` comment on the Go struct field (Go's standard convention; `go vet` and `staticcheck` honor it via `SA1019` / similar) — is emitted on Go types regenerated from AdCP schemas where the source schema declares `deprecated: true`. Anchor: `CreateMediaBuySuccess.Status` and `UpdateMediaBuySuccess.Status` in AdCP 3.1+.
-
Or a codegen-pipeline change that injects the `// Deprecated:` comment from the JSON Schema `deprecated` keyword / description-level deprecation text, if the underlying tool doesn't propagate it.
The bar is: a buyer's Go code reading `response.Status` on `CreateMediaBuySuccess` gets a `staticcheck SA1019` (or equivalent linter) warning in 3.1, so the deprecation is visible at compile/lint time rather than only at runtime via the storyboard certification gate.
Why the toolchain matters
The protocol-side expert review flagged this exactly:
`quicktype` (used by some Go paths) does not propagate it at all. The compliance-storyboard assertion (`path: "media_buy_status"`) is doing the real enforcement work; the schema marker is advisory at best for Go and old-Pydantic adopters.
If the codegen tool can't be configured to emit `// Deprecated:` comments, the right move may be a post-processing step that reads the source schemas, identifies `deprecated: true` properties, and injects the comment block onto the matching Go struct field before commit.
Related
Filed in response to adcontextprotocol/adcp#4904 (the 3.1 additive-deprecate on `CreateMediaBuySuccess` / `UpdateMediaBuySuccess` body-level `status`). The expert review on that PR flagged that JSON Schema `deprecated: true` propagation through Go codegen tools is often not propagated at all (`quicktype` and similar drop it).
What's needed
Either:
A unit test that asserts a deprecation surface — typically a `// Deprecated:` comment on the Go struct field (Go's standard convention; `go vet` and `staticcheck` honor it via `SA1019` / similar) — is emitted on Go types regenerated from AdCP schemas where the source schema declares `deprecated: true`. Anchor: `CreateMediaBuySuccess.Status` and `UpdateMediaBuySuccess.Status` in AdCP 3.1+.
Or a codegen-pipeline change that injects the `// Deprecated:` comment from the JSON Schema `deprecated` keyword / description-level deprecation text, if the underlying tool doesn't propagate it.
The bar is: a buyer's Go code reading `response.Status` on `CreateMediaBuySuccess` gets a `staticcheck SA1019` (or equivalent linter) warning in 3.1, so the deprecation is visible at compile/lint time rather than only at runtime via the storyboard certification gate.
Why the toolchain matters
The protocol-side expert review flagged this exactly:
If the codegen tool can't be configured to emit `// Deprecated:` comments, the right move may be a post-processing step that reads the source schemas, identifies `deprecated: true` properties, and injects the comment block onto the matching Go struct field before commit.
Related
status(TaskStatus) collides with payloadstatus(MediaBuyStatus) at the same top-level key on create/update/cancel_media_buy adcp#4895 — issue driving the 3.1 additive-deprecatestatuson CreateMediaBuySuccess / UpdateMediaBuySuccess (3.2) adcp#4906 — 3.2 follow-up that removes the deprecated fieldstatustomedia_buy_statuson get_media_buys / get_media_buy_delivery / core/media-buy adcp#4905 — 4.0 nested cascade@deprecatedJSDoc generation on deprecated JSON Schema properties adcp-client#1915 — TypeScript SDK equivalent