search

WICG / turtledove

TURTLEDOVE
https://wicg.github.io/turtledove/
Other
526 stars 228 forks source link

Updated list of what can be a promise #1298

Open patmmccann opened 1 week ago

patmmccann commented 1 week ago

Several things that cannot be a promise seem to not have good reason to be excluded, eg

sellerExperimentGroupId perBuyerExperimentGroupIds perBuyerCurrencies

As async auctions become more popular, it would be useful to have as much as possible as a promise. Currently the fledge explainer lists these: "The values of some signals (those configured by fields auctionSignals, sellerSignals, perBuyerSignals, perBuyerTimeouts, deprecatedRenderURLReplacements, and directFromSellerSignals) can optionally be provided not as concrete values, but as Promises."

Is that a full list?

patmmccann commented 1 week ago

cc @mkendall @dgirardi

morlovich commented 1 week ago

perBuyerCurrencies can actually be a promise... but I just discovered a bug in handling of it this week that we may not correctly depend on it resolving for checking the currency of a component auction against top-level's perBuyerCurrencies. A good way of checking this is the IDL: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/ad_auction/auction_ad_config.idl;drc=8a1af0ea61be0130a549952082c59f717f1ab1a0;l=37

On Thu, Oct 10, 2024 at 10:55 AM Patrick McCann @.***> wrote:

Several things that cannot be a promise seem to not have good reason to be excluded, eg

sellerExperimentGroupId perBuyerExperimentGroupIds perBuyerCurrencies

As async auctions become more popular, it would be useful to have as much as possible as a promise. Currently the fledge explainer lists these: "The values of some signals (those configured by fields auctionSignals, sellerSignals, perBuyerSignals, perBuyerTimeouts, deprecatedRenderURLReplacements, and directFromSellerSignals) can optionally be provided not as concrete values, but as Promises https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise ."

Is that a full list?

— Reply to this email directly, view it on GitHub https://github.com/WICG/turtledove/issues/1298, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4XKRGG2CH3IURSEO3BXG3Z22IOHAVCNFSM6AAAAABPW7RLLSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGU3TSMJRGAZTCNY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

patmmccann commented 1 week ago

cc https://github.com/prebid/Prebid.js/pull/12205

patmmccann commented 1 week ago

@morlovich that list is extremely helpful, it seems a Pr on the explainer with the full list is in order? Referencing that list isn't the most user friendly thing :) Works for me, but seems awkward if I point to it in documentation

JacobGo commented 1 week ago

+1, I'd also add perBuyerGroupLimits and perBuyerMultiBidLimits to the feature request list. There's certain fields that can't be deferred though, e.g.perBuyerExperimentGroupIds must be passed on the DSP lookup.

I do hope that as part of maturing Protected Audience / Ad Selection API, browsers will code-generate TypeScript interfaces from the IDLs like other web APIs.

dmdabbs commented 1 week ago

Also maybe perBuyerCumulativeTimeouts, if I correctly read latest published spec:

Promise<record<USVString, any>> perBuyerSignals; Promise<record<USVString, unsigned long long>> perBuyerTimeouts; Promise<record<USVString, unsigned long long>> perBuyerCumulativeTimeouts;

MattMenke2 commented 1 week ago

perBuyerGroupLimits as a promise would mean we can't start loading buyer scripts, so it seems not too useful as a promise, since we effectively can't do anything, at least for any component auction without it set yet, though if we care about values like that, it would seems simpler to allow entire componentAuctions to be promises.

rdgordon-index commented 3 days ago

perBuyerGroupLimits as a promise would mean we can't start loading buyer scripts

Wouldn't there still be value here in limiting how many IGs to execute per component seller, even if they have been loaded?

It would seems simpler to allow entire componentAuctions to be promises.

That's an interesting option, since it avoids the all-or-nothing promise at the top-level seller level.

MattMenke2 commented 3 days ago

Wouldn't there still be value here in limiting how many IGs to execute per component seller, even if they have been loaded?

What if an IG we had been asked to exclude had already won the auction?

rdgordon-index commented 3 days ago

What if an IG we had been asked to exclude had already won the auction?

Not sure I follow -- the auction wouldn't start until the rest of the promises had resolved (like auctionSignals, sellerSignals, and perBuyerGroupLimits), which are needed to make any sense of the bids...

MattMenke2 commented 3 days ago

Not sure I follow -- the auction wouldn't start until the rest of the promises had resolved (like auctionSignals, sellerSignals, and perBuyerGroupLimits), which are needed to make any sense of the bids...

If we can't start the auction, there's not much point in using promises - which was why I was saying it was not useful.

rdgordon-index commented 3 days ago

Well, you can start the auction -- in the sense that script runners can be fired up, KV calls can be initiated etc. -- but you're talking about an auction winner above....

MattMenke2 commented 2 days ago

So you're proposing a new stage to auctions, where we have bids (which may or may not be scored), but haven't applied the group limit filter on them, and then we can apply the group limit to the bids. It's doable, but it very much can't just be lumped into how we handle other promises, because of that new phase. I'm skeptical it's worth the complexity for just letting that one field be a promise, though not my call.