Skip to content
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

Pass through unknown imp.ext values to adapters #3878

Merged

Conversation

justadreamer
Copy link
Contributor

Addresses "Stop hard-failing on unknown imp.ext values" #3735
The behavior is as described in the issue:

  1. If imp.ext.prebid.bidder exists, then do nothing. The requestor has moved to the new syntax where bidders are in imp.ext.prebid and there's no need to check imp.ext anymore. Let it through.
  2. If imp.ext.prebid.bidder doesn't exist, then it's ok to warn about unknown values, but the request should otherwise proceed.

In any case imp.ext.foo will be let through, in the second case with a warning.

NOTE: with "test":1 flag present in the request payload - the debug.resolvedrequest will contain the passed imp.ext.foo, however many bidder adapters do their own sanitization of imp.ext.* fields and as a result many will not send it to their servers. The example of one that transparently passes imp.ext fields was aax - so can be used for testing to see what actual bidder sends.

@osazos
Copy link
Contributor

osazos commented Nov 12, 2024

Hi, as the issue addressed here seems quite impacting, is there a reason to keep this PR without activity since 2 months?

@shahinrahbariasl
Copy link
Contributor

shahinrahbariasl commented Nov 14, 2024

Hi, as the issue addressed here seems quite impacting, is there a reason to keep this PR without activity since 2 months?

Agreed, this is particularly pressing as Privacy Sandbox support for the latest PBS Go versions is currently affected by this unresolved issue.

exchange/utils.go Outdated Show resolved Hide resolved
ortb/request_validator.go Outdated Show resolved Hide resolved
@@ -22,5 +22,5 @@
}
},
"expectedReturnCode": 400,
"expectedErrorMessage": "Invalid request: request.imp[0].ext.prebid.bidder contains unknown bidder: noBidderShouldEverHaveThisName. Did you forget an alias in request.ext.prebid.aliases?\n"
"expectedErrorMessage": "Invalid request: request.imp[0].ext contains unknown bidder: 'noBidderShouldEverHaveThisName', ignoring"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting. Since the bidder name check is just a warning, this should fail because there are no bidders. Why is there not an error message with lack of bidders found?

Copy link
Contributor Author

@justadreamer justadreamer Nov 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the test uses assert.Contains() checking that expectedErrorMessage is within actualErrorMessage.
actualErrorMessage contained 2 error messages (this one was added as errortypes.Warning) and one of them was added as a proper error: Invalid request: request.imp[0].ext.prebid.bidder must contain at least one bidder - so request failed with this one. I've resurrected proper expected error message in this test, as the request indeed fails because of no bidders

"profile": 1234
}
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this test affected?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test was affected because it had an empty imp.ext.prebid.bidder object defined in the request, and all the bidders were specified outside of it. According to the new logic if there is an imp.ext.prebid.bidder object (even if it is empty one) - we must consider that the publisher has switched to the new way of specifying bidders and ignore the bidders in imp.ext - treat them as arbitrary fields and pass along as is. Thus we had 3 options:

  1. modify the test fixture and remove an empty prebid.bidder: {}
  2. modify the test fixture and promote the bidders from imp.ext into imp.ext.prebid.bidder
  3. Modify the condition of promotion in request_validator.go: instead of promoting only when prebid.Bidder==nil here:
if prebid.Bidder == nil {
    prebid.Bidder = make(map[string]json.RawMessage)
    bidderPromote = true
}

also promote in case it is empty: if prebid.Bidder == nil || len(prebid.Bidder) == 0
but this would disrupt the other tests logic.

So we took option 2. I think route 1 is less invasive, so I am adding a lighter modification to this test fixture - where it will only remove an empty prebid.bidder: {} object.

"skadn": json.RawMessage(`"anySKAdNetwork"`),
"gpid": json.RawMessage(`"anyGPID"`),
"tid": json.RawMessage(`"anyTID"`),
"unknownBidder": json.RawMessage(`"anyUnknownBidderValues"`),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: unknownBidder doesn't seem right for these test cases, as it's now interpreted as just an unknown value and is not checked for as a bidder.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed to arbitraryKey: arbitraryValue

@@ -140,6 +154,12 @@ func TestValidateImpExt(t *testing.T) {
expectedImpExt: `{"prebid":{"bidder":{"appnexus":{"placement_id":555}}}}`,
expectedErrs: []error{},
},
{
description: "Valid bidder root ext + Empty Prebid Bidder",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a comment to explain the valid bidder is ignored because prebid.bidder is present.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added

@justadreamer justadreamer force-pushed the unknown-imp-ext-values-support branch from b82c1e3 to fa8fdf7 Compare November 20, 2024 15:26
instead of promoting bidders from imp.ext to imp.ext.prebid.bidder, just remove empty imp.ext.prebid.bidder
@justadreamer
Copy link
Contributor Author

Hi @SyntaxNode the review comments above were addressed.

Copy link
Collaborator

@bsardo bsardo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking good; I have just a couple of minor comments. Just a reminder, please push up new commits going forward instead of rebasing and force pushing to make delta reviews easier 😄

Comment on lines 101 to 113
// promote imp[].ext.BIDDER to newer imp[].ext.prebid.bidder.BIDDER location, with the later taking precedence
for k, v := range ext {
if openrtb_ext.IsPotentialBidder(k) {
if _, exists := prebid.Bidder[k]; !exists {
prebid.Bidder[k] = v
prebidModified = true
if bidderPromote {
for k, v := range ext {
if openrtb_ext.IsPotentialBidder(k) {
if _, exists := prebid.Bidder[k]; !exists {
prebid.Bidder[k] = v
prebidModified = true
}
delete(ext, k)
extModified = true
}
delete(ext, k)
extModified = true
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SyntaxNode with this change we will now only attempt to promote from imp[].ext to imp[].ext.bidder if imp[].ext.bidder does not exist. This is what is called out in the issue and what PBS-Java does. Just confirming that we are ok with that approach now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more option would be to allow for an empty imp.ext.prebid.bidder object i.e. {} - and promote in that case too, but Perhaps helps in case someone was unintentionally adding this object into requests, but not filling it, but I don't think there are clients that do this...

Copy link
Contributor

@SyntaxNode SyntaxNode Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I vote to keep this as-is.

This is what is called out in the issue and what PBS-Java does. Just confirming that we are ok with that approach now.

Yes. This is the design of the feature and the next phase of deprecating imp[].ext for bidder parameters. It should've never been designed this way, but here we are.

but I don't think there are clients that do this...

Right. Let's not code for unknown use cases.

ortb/request_validator.go Outdated Show resolved Hide resolved
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way you've modified this test it is now a valid test case instead of an invalid test case and is in the wrong directory. How about doing the following instead:

  1. Rename this test to imp-ext-prebid-bidder-empty.json and modify this test case to result in a 400 status code with imp.ext.bidder being empty
  2. Rename endpoints/openrtb2/sample-requests/valid-whole/supplementary/req-ext-bidder-params-backward-compatible-merge.json to endpoints/openrtb2/sample-requests/valid-whole/supplementary/req-ext-bidder-params-promotion.json and include a field that is not a bidder ensuring the warning is reported in addition to the known bidders being promoted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense, sorry did not pay attention to the semantics expressed by directory names.

  1. done
  2. done, but now that I have added this test for the warning, I see that the warning code we have introduced is 0, perhaps it should be either unknownWarningCode or some new warning code for this specific warning?

"skadn": json.RawMessage(`"anySKAdNetwork"`),
"gpid": json.RawMessage(`"anyGPID"`),
"tid": json.RawMessage(`"anyTID"`),
"unknownBidder": json.RawMessage(`"anyUnknownBidderValues"`),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in an earlier comment I think it makes more sense if all of these test cases in TestCreateSanitizedImpExt with key "unknownBidder" use "arbitraryField" instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be addressed now in utils_test.go

@SyntaxNode SyntaxNode mentioned this pull request Nov 25, 2024
Copy link
Collaborator

@hhhjort hhhjort left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@bsardo bsardo merged commit 56b72c1 into prebid:master Nov 26, 2024
3 checks passed
scr-oath pushed a commit to scr-oath/prebid-server that referenced this pull request Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants