Skip to content

get_media_buy_delivery silently ignores time_granularity / include_window_breakdown (no windows[], no UNSUPPORTED_GRANULARITY) #1711

Description

@numarasSigmaSoftware

Observed

The get_media_buy_delivery request accepts windowed-reporting fields that production silently ignores.

adcp==6.6.0's GetMediaBuyDeliveryRequest carries time_granularity and include_window_breakdown, but git grep finds zero handling anywhere in src/: no windows[] emission on the response, no UNSUPPORTED_GRANULARITY error, and no reporting_capabilities.windowed_pull_granularities advertisement. A buyer that sets time_granularity today receives a normal response carrying neither the windows nor an error.

Expected

AdCP 3.1.1, dist/schemas/3.1.1/media-buy/get-media-buy-delivery-response.json, windows description (verbatim):

Sellers MUST exclude this field when time_granularity is omitted; when set, sellers MUST honor pulls at any granularity in reporting_capabilities.windowed_pull_granularities (otherwise return UNSUPPORTED_GRANULARITY).

Either behavior is conformant — honor the pull, or reject with UNSUPPORTED_GRANULARITY and advertise the supported set. Silently ignoring the field is neither, and it violates this repo's "No Quiet Failures" rule (CLAUDE.md).

Related second gap: row-level finality

MediaBuyDeliveryData does not emit is_final / finalized_at. Deferring this is defensible today — the MUST is conditional ("Sellers MUST NOT emit is_final: true … unless every entry in by_package has is_final: true for the same measurement_window"), absence is explicitly permitted ("When absent, the seller does not distinguish provisional from final at the row level"), and neither field is in the item's required list. Noting it here because the GAM adapter already computes per-package finality, so emitting it is feasible and belongs with the windowed-reporting work.

Provenance

Pre-existing, not introduced by any single PR — the request fields arrived with the adcp 6.6.0 / spec 3.1.1 bump (#1585). Surfaced during the #1575 review; explicitly out of that PR's scope (its diff does not touch these paths).

Notes for whoever picks this up

Ground the capability-advertisement question in the pinned spec before writing code, per CLAUDE.md's Spec-Grounding Gate — read dist/schemas/3.1.1/ and the implementation prose verbatim (gh api repos/adcontextprotocol/adcp/contents/<path>?ref=v3.1.1 --jq .content | base64 -d), not a summarizer and not the SDK alone. The SDK is a cross-check, never the authority.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status
    Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions