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

Debug warnings #1724

Merged
merged 6 commits into from
Mar 18, 2021
Merged

Debug warnings #1724

merged 6 commits into from
Mar 18, 2021

Conversation

VeronikaSolovei9
Copy link
Contributor

No description provided.

@@ -87,6 +87,8 @@ type pbsOrtbSeatBid struct {
// if len(bids) > 0, this will become response.seatbid[i].ext.{bidder} on the final OpenRTB response.
// if len(bids) == 0, this will be ignored because the OpenRTB spec doesn't allow a SeatBid with 0 Bids.
ext json.RawMessage

warnings map[openrtb_ext.BidderName][]openrtb_ext.ExtBidderError
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Warnings are actually Errors. Should I use errortypes.Warning instead? If yes - I need to add Code in it:

type Warning struct {
	Message string
	Code int
}

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree it's a bit strange to see warnings as a collection of errors. This only a concern in code with the type name. I'm not sure its worth having two separate but identical data structures with different names, but I don't feel too strongly if you prefer to see ExtBidderWarning.

Copy link
Collaborator

Choose a reason for hiding this comment

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

It is reasonable to me that warnings are a subset of go "errors". If you need to define Warning in more than one package, then I would just add it to errortypes. If it appears in just one place, I don't have a strong feeling on it.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Too be clear, I don't have an issue with warnings map[openrtb_ext.BidderName][]openrtb_ext.ExtBidderError appearing in multiple places, just the idea of defining a Warning struct multiple places.

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 new(or updated) Warning should also have json properties mapping.

type ExtBidderError struct {
	Code    int    `json:"code"`
	Message string `json:"message"`
}

Please advice. I'll do what you guys think is better.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I lean towards just using ExtBidderError and using the Code value to determine the type. A "warning" can also be called a "non-fatal error", it is a problem, just not a problem severe enough to require aborting the processing. A new struct that is identical to an old struct should really just be used when type safety is an important concern. There is a large channel (communicating issues out to the requester) where we want to treat them interchangeably, to a degree, and just a few places where we want to separate them out. I am open to being convinced otherwise.

Copy link
Contributor Author

@VeronikaSolovei9 VeronikaSolovei9 Mar 2, 2021

Choose a reason for hiding this comment

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

I'm confused.
Code in ExtBidderError is an error number like UnknownWarningCode = 10999 and it doesn't have severity level.
Code in Warning is Severity level and Warning doesn't have integer error code.

Do you mean I need to "consolidate" these structures?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I reviewed again and I see the warnings are their own thing now in the code. I suppose it depends on future plans, if we want to reuse some of the error machinery for warnings in the future, then we should keep them consolidated. If this is the extent we want to have warnings, then we can consider making them their own struct.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Per morning discussion I renamed ExtBidderError to more generic ExtBidderMessage.
Should we leave it all as it is now?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I am good with that.

hhhjort
hhhjort previously approved these changes Mar 4, 2021
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

exchange/bidder.go Show resolved Hide resolved
exchange/bidder.go Outdated Show resolved Hide resolved
exchange/bidder.go Outdated Show resolved Hide resolved
endpoints/openrtb2/amp_auction.go Show resolved Hide resolved
exchange/exchange.go Outdated Show resolved Hide resolved
@VeronikaSolovei9
Copy link
Contributor Author

All comments addressed, code refactored as discussed with team

hhhjort
hhhjort previously approved these changes Mar 9, 2021
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

Copy link
Contributor

@SyntaxNode SyntaxNode left a comment

Choose a reason for hiding this comment

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

I successfully performed end to end testing with the auction endpoint for account and bidder debug warnings. Does this include AMP and Video endpoint warning wire-up?

I wasn't able to get a CCPA warning for the auction endpoint. Do you want to wire that up now or in a follow-up PR?

exchange/exchange_test.go Outdated Show resolved Hide resolved
exchange/exchange_test.go Outdated Show resolved Hide resolved
@VeronikaSolovei9
Copy link
Contributor Author

I tested it for video and auction endpoints, but not for AMP.
What is the use case for CCPA warning?

@SyntaxNode
Copy link
Contributor

What is the use case for CCPA warning?

The CCPA string is invalid. It is removed from the request and a warning is returned to the publisher. An example invalid is the literal string "invalid".

@VeronikaSolovei9
Copy link
Contributor Author

Still need to add more tests for AMP endpoint

@VeronikaSolovei9
Copy link
Contributor Author

Ready for review

hhhjort
hhhjort previously approved these changes Mar 16, 2021
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

exchange/exchange.go Outdated Show resolved Hide resolved
exchange/exchange.go Outdated Show resolved Hide resolved
endpoints/openrtb2/amp_auction_test.go Outdated Show resolved Hide resolved
endpoints/openrtb2/amp_auction_test.go Outdated Show resolved Hide resolved
endpoints/openrtb2/amp_auction_test.go Show resolved Hide resolved
endpoints/openrtb2/auction_test.go Show resolved Hide resolved
exchange/exchange.go Outdated Show resolved Hide resolved
@@ -179,6 +180,7 @@ func (deps *endpointDeps) Auction(w http.ResponseWriter, r *http.Request, _ http
RequestType: labels.RType,
StartTime: start,
LegacyLabels: labels,
Warnings: warnings,
Copy link
Contributor

Choose a reason for hiding this comment

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

To Other Reviewers: This is necessary evil right now since HoldAuction is also composing the endpoint response. We'll need to separate these behaviors in the future, but that's too much work to do here.

exchange/exchange_test.go Outdated Show resolved Hide resolved
exchange/exchange_test.go Outdated Show resolved Hide resolved
{nil, false, nil},
{nil, true, tc2Wrnings},
{&openrtb_ext.ExtRegs{USPrivacy: "invalid"}, true, tc3Wrnings},
{&openrtb_ext.ExtRegs{USPrivacy: "1NYN"}, false, tc4Wrnings},
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice. I think we can go one step further to using named field setters and embedding the expected warnings:

testData := []inputTest{
	{
		regs:              nil,
		invalidConsentURL: false,
		expectedWarnings:  nil,
	},
	{
		regs:              nil,
		invalidConsentURL: true,
		expectedWarnings: map[openrtb_ext.BidderName][]openrtb_ext.ExtBidderMessage{
			openrtb_ext.BidderReservedGeneral: {invalidCCPAWarning},
		},
	},
	{
		regs:              &openrtb_ext.ExtRegs{USPrivacy: "invalid"},
		invalidConsentURL: true,
		expectedWarnings: map[openrtb_ext.BidderName][]openrtb_ext.ExtBidderMessage{
			openrtb_ext.BidderReservedGeneral: {invalidCCPAWarning, invalidConsentWarning},
			openrtb_ext.BidderAppnexus:        {bidderWarning},
		},
	},
	{
		regs:              &openrtb_ext.ExtRegs{USPrivacy: "1NYN"},
		invalidConsentURL: false,
		expectedWarnings: map[openrtb_ext.BidderName][]openrtb_ext.ExtBidderMessage{
			openrtb_ext.BidderAppnexus: {bidderWarning},
		},
	},
}

type mockAmpExchangeWarnings struct{}

func (m *mockAmpExchangeWarnings) HoldAuction(ctx context.Context, r exchange.AuctionRequest, debugLog *exchange.DebugLog) (*openrtb.BidResponse, error) {
//m.lastRequest = r.BidRequest
Copy link
Contributor

Choose a reason for hiding this comment

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

Please remove commented out code.

}

for _, warning := range r.Warnings {
//typedWarning := warning.(*errortypes.Warning)
Copy link
Contributor

Choose a reason for hiding this comment

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

Please remove commented out code.

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.

3 participants