initial update for bidder schain support - feedback wanted #4479
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Type of change
Description of change
This is a Work In Progress for bidder specific schain changes.
I would like to get feedback on this initial approach, which is a bit different that what was proposed in #4465.
Summary of module (in this draft state):
adapterManager.makeBidRequests
function has executed, the module will be called to process theschain
config(s).validation
setting and either setschain.config
object on thebidRequest.bids.schain
field. This field will not be set If either: thevalidation
isstrict
and the schain config is setup incorrectly or the overallschain
object was not an object.bidRequests
, the auction will resume as normal. Bidders will read thisbidRequest
schain
field (as they did before) and set it in their request.What's different against the proposal:
schain
in an auction object for them to read later.bidRequest
'sschain
field instead of callingconfig.getConfig('schain');
(so that prebid will dynamically pull the bidder'sschain
).The main reasons for this shift was: a set of limitations I encountered when attempting to invalidate an
schain
object within the Prebidconfig
objects and how making bidders use theconfig.getConfig
with some type of a workaround for the limitations would feel. See details below...Troubles on overwriting the Prebid Configs
I tried to overwrite the schain config by re-executing the
setBidderConfig
(andsetConfig
) in the following manners:In the null case - it passed through the
setBidderConfig
function and made itnull
. But when I called theconfig.getConfig
in the bidder - it always pulled the globalschain
config instead of justnull
. This was due to this logic check here; it thought there was no bidderConfig defined for this topic, so it fell back to the global.In the {} case - the overwrite didn't work in the
setBidderConfig
due to the Object.assign here; since the existing bidder config was listed before the new config (and there were no new values to overwrite), the bidder config stayed put.In the 'invalid
string case - this actually worked in both the
setBidderConfigand in the
config.getConfig` in the bidder. But this didn't seem to be ideal way to manage the implementation for the bidders.Using config listeners to evaluate the config as its submitted
I also attempted to look into using the
subscribe()
andlisteners
functionality from theconfig.js
file to do the config evaluation right after it was registered by thepbjs.setConfig()
; this is done by registering a callback function using `config.getConfig('module', function()...); in the module file.While this approach loaded the global
schain
config for us to read, thissubscribe
/listener
functionality is not currently setup for thesetBidderConfig
. Given the limited functionality, this approach didn't seem like it would pan-out.Inserting schain in auction object again for bidders
Given the results above and that we couldn't cleanly overwrite the prebid configs, I thought to continue using the approach to pass in a value in the bidRequests for the bidder to read.
I toyed with some flags that would set for each bidder so they'd know to call the
config.getConfig
, but this didn't really make sense and looked like an extra step the bidder had to go through. The module was already capable of finding the correctschain
config for that bidder (whether it was the global or an override), so it could easily pass the correct config to that bidder in a controlled, secure manner.This final approach is what I implemented (currently) in this draft PR as it seemed to be a more ideal setup.
If you got this far - thanks for reading through the above. :) If you have any suggestions or other ideas to try out so that we're more in-line with the original proposal, please feel free to share.
Thanks.