-
Notifications
You must be signed in to change notification settings - Fork 769
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request imp format can generate errors for adapters that don't support a certain format. #2178
Comments
Got a report that PBS-Java also have an issue in this area. It's not enforcing the mediatype rules at all.e.g. if a bid adapter's config doesn't list 'native', it's not removing imp.native from the request before sending to the adapter. Will open an internal ticket. |
We recently hit this error with one of our bidders (PBS-Java). We pulled the bidder until a resolution is found. To me, it only looks to be an issue if the bidder test checks for unsupported media types. I say this because we have other s2s bidders in play that do not support native but are not producing an error because they do not check for such in their bidder test. Ideally, PBS core would remove unsupported media types from the imp, but to me it looks like the current structure of the imp wouldn't allow this because the media types are not specific to the bidder - they are applied to the slot. |
@coreyb-cbs - PBS-core makes an adapter-specific version of the ORTB request. It will remove the mediatypes from that copy of the object. Will move that fix up in the priority a bit. |
@bretg following up... was a fix/PR ever created for this? |
A PBS-Java update is in the works. Would guess it can be released with v1.90. i.e. not the next release (1.89), but the one after. |
@AlexBVolcy will be handling this for PBS-Go |
Released with PBS-Java 1.92 |
Implemented in PBS-Go 0.228.0. |
PBS core has a filter step that removes any formats from an imp sent to an adapter that the adapter does not support. This is good, except we also generate an error in the response indicating that an adapter does not support a particular format. This can add unnecessary noise to analytics, in some cases such errors are unavoidable.
For example, adapter A supports banner and native. Adapter B banner only. Publisher has a multiformat imp that supports both banner and native. To avoid the error from being generated for adapter B, the publisher will have to send a banner only request, missing out on any native demand available from adapter A.
I suggest we downgrade this from an error to a warning, or perhaps forgo it completely as long as there is at least one adapter that supports each format supplied. We probably still want an error if there are no adapters able to service a format requested in a request.
The text was updated successfully, but these errors were encountered: