Skip to content

Bugfix: returnCreative handling by cache type - #4898

Open
MichaelErmer wants to merge 3 commits into
prebid:masterfrom
MichaelErmer:fix/cache-return-creative-by-media-type
Open

Bugfix: returnCreative handling by cache type#4898
MichaelErmer wants to merge 3 commits into
prebid:masterfrom
MichaelErmer:fix/cache-return-creative-by-media-type

Conversation

@MichaelErmer

@MichaelErmer MichaelErmer commented Aug 5, 2026

Copy link
Copy Markdown

Problem observed

We observed successful banner bids that could not render after moving traffic to PBS-Go. The bidder raw OpenRTB response contained adm, but the final PBS-Go response did not. At the same time:

  • nurl and lurl were still present
  • GAM targeting such as hb_bidder and hb_price was still populated
  • no client-side blocking was visible

This made the auction look successful in GAM, but without adm there was no creative to render. As a result, impression trackers contained in the creative were never executed and the bidders recorded no impressions.

The request did not ask PBS to suppress banner creative. It only configured ext.prebid.cache.vastxml.returnCreative=false, which should affect cached VAST for video bids.

Root cause

PBS-Go collapsed cache.bids.returnCreative and cache.vastxml.returnCreative into one global boolean before building the response. When vastxml.returnCreative was false, makeBid therefore cleared adm for every returned bid, including banners.

This also made it impossible to vary returnCreative by media type as described in #2584.

Expected behavior and PBS-Java parity

PBS-Java keeps the two cache targets independent when deciding whether to include adm:

  • cache.bids applies to all bid types
  • cache.vastxml applies only to video bids
  • if an applicable cache target has returnCreative=false, adm is omitted for that bid
  • a VAST-only returnCreative=false setting does not remove adm from banner bids

This means the observed request keeps banner adm while still removing video adm. Combined bids and vastxml settings now follow the same precedence as PBS-Java as well.

The corresponding PBS-Java behavior is implemented in BidResponseCreator and covered by its cache functional tests.

Fix

  • preserve the bids and VAST returnCreative values separately
  • evaluate them after the bid media type is known
  • apply VAST creative suppression only to video bids
  • add regression coverage for banner, video, and combined cache settings

Fixes #2584

Testing

  • go test ./...
  • go test ./exchange -count=1
  • go vet ./exchange
  • gofmt -s on changed files

@MichaelErmer MichaelErmer changed the title Fix returnCreative handling by cache type Bugfix: returnCreative handling by cache type Aug 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unable to vary returnCreative on media type

1 participant