Skip to content

Add contextual TKV signals to PA Explainer #1429

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

MattMenke2
Copy link
Contributor

Proposal to add contextual TKV signals that will only be sent to TEE-based servers.

There are a couple ambiguities here that this PR proposes behavior for, but feedback would be much appreciated on. In particular:

  • Should time spent waiting on a unique per-bidder promise count towards the bidder's cumulative timeout? We could allow this to be configured via the AuctionConfig, but of course, that's yet more complexity.
  • If the promise fails, what should we do? It seems simplest to not run generateBid() at all for that bidder, even for IGs that use v1 servers or have no signals request. This is because we likely will need to delay running those generateBid() calls until we have the contextual signals, anyways (to avoid either having to load the bidder twice, or keeping the bidder around, consuming out global process quota). We could alternatively provide no signals to the server and still send the request, or only make generateBid() calls for IGs that don't use a TEE-based TKV that can receive the data.

The current plan is to hold off on loading a bidder's script (and thus assigning a process, which we have a cap on) until the per-bidder promise is resolved. That could impact performance, but keeping a bidder process around while waiting on a promise to resolved is also a potential source of performance issues, including deadlock until a promise is resolved, if this is happening for enough buyers at once.

Proposal to add contextual TKV signals that will only be sent to TEE-based servers.

There are a couple ambiguities here that this PR proposes behavior for, but feedback would be much appreciated on. In particular:

* Should time spent waiting on a unique per-bidder process count towards the bidder's cumulative timeout? We could allow this to be configured via the AuctionConfig, but of course, that's yet more complexity.
* If the promise fails, what should we do? It seems simplest to not run generateBid() at all for that bidder, even for IGs that use v1 servers or have no signals request. This is because we likely will need to delay running those generateBid() calls until we have the contextual signals, anyways (to avoid either having to load the bidder twice, or keeping the bidder around, consuming out global process quota).  We could alternatively provide no signals to the server and still send the request, or only make generateBid() calls for IGs that don't use a TEE-based TKV that can receive the data.
Fix typo.
@MattMenke2 MattMenke2 changed the title Add contextual TKV signals Add contextual TKV signals to PA Explainer Apr 28, 2025
Relax constraints on rejected promises
@MattMenke2
Copy link
Contributor Author

MattMenke2 commented Apr 28, 2025

I've relaxed the behavior around other IGs for the same buyer that don't use a KVv2 signals URL - they're no longer affected by promise resolution being rejected.

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.

1 participant