MobileFuse Adapter: Update to support OpenRTB MType#1
Conversation
| case openrtb2.MarkupVideo: | ||
| return openrtb_ext.BidTypeVideo | ||
| default: | ||
| return openrtb_ext.BidTypeBanner |
There was a problem hiding this comment.
@dtbarne do we want to still keep banner type as a fallback or resolve to error.
There was a problem hiding this comment.
I think either is sensible, though I'm leaning toward resolving to an error because it would probably be easier for a pub to troubleshoot if there is an issue.
There was a problem hiding this comment.
@dtbarne I refactored to resolve to error whenmtype is missing. could check it out again?
| default: | ||
| return openrtb_ext.BidTypeBanner | ||
| return "", &errortypes.BadServerResponse{ | ||
| Message: fmt.Sprintf("Unsupported MType \"%d\" for impression ID \"%s\"", bid.MType, bid.ImpID), |
There was a problem hiding this comment.
Did you check how other bidders handle it? That may be best
There was a problem hiding this comment.
Of course. In other implementations there are nuance differences (e.g. return error or fallback type, early return when any bid has error or return valid bids and additionally errors). I think that this PR is best of these worlds.
I created internal PR to mostly verify that it's fine for us to keep banner media type as a fallback (what also exists in some of other implementations) or thrown an error when mtype is missing. It's a detail however good to verify it.
…e-for-bid-type-detection
|
close due creating official PR after internal review |
2 participants
This PR updates the MobileFuse adapter to utilize the standard OpenRTB
MTypefield for determining bid types, replacing the legacyext.mf.media_typecustom logic.Key Changes:
extJSON to checking the nativebid.MType.ExtMf,BidExt) and logic used solely for parsing the legacy field.getBidTypeto return aBadServerResponseerror ifMTypeis missing or unsupported, rather than defaulting to Banner. Valid bids within the same response are still processed successfully.