[Spec] Handle B&A server response promise

[qingxinwu]

---

Preview | Diff

[qingxinwu]

check if this struct's field can be uint8array, or needs another Infra data structure, like byte sequence. If so, need to do convert javascript to infra value on it here.

[brusshamilton]

I think it's okay to leave it as a Uint8Array, but we probably need to copy or transfer (https://webidl.spec.whatwg.org/#arraybuffer-transfer) the underlying storage. UInt8Array is really just a shallow pointer to a buffer. We're going to be accessing it [=in parallel=] and we want to specify that later changes to the provided array in the main context won't affect the version we are using in the parallel context.

[qingxinwu]

how about this https://webidl.spec.whatwg.org/#dfn-get-buffer-source-copy? I saw it used in fetch API (step 1.3 of https://fetch.spec.whatwg.org/#incrementally-read-loop). (oh, it notes "Implementations are strongly encouraged to use an implementation strategy that avoids this copy where possible").
Does it match our intention?

[brusshamilton]

Yes, I would prefer a transfer here over a copy. With a transfer the value in the array is undefined after a call, but allows implementations to optimize. We perform a copy on Chrome because of IPC, but there's no reason to require a copy.

[qingxinwu]

got it. Done.

[qingxinwu]

@brusshamilton PTAL. Thanks
@morlovich Since you wrote the other promise handling part, PTAL as well. Thanks!

[brusshamilton]

I think it's okay to leave it as a Uint8Array, but we probably need to copy or transfer (https://webidl.spec.whatwg.org/#arraybuffer-transfer) the underlying storage. UInt8Array is really just a shallow pointer to a buffer. We're going to be accessing it [=in parallel=] and we want to specify that later changes to the provided array in the main context won't affect the version we are using in the parallel context.

[morlovich]

LGTM

[qingxinwu]

@morlovich After reading it more, I think we need to decrement |pendingComponentAuctions| in these cases, otherwise the step below that waits for |pendingComponentAuctions| to be 0 will keep waiting? WDYT

[morlovich]

Good catch. I think we may abort less then the implementation (just a component and not the whole thing) when this happens, too?

[qingxinwu]

hmm yes, but if we check [=recursively wait until configuration input promises resolve=] first before "|compWinnerInfo| is failure" here, any component promise failure will fail all component auctions (not top level though, but top level would have no winner from component auctions)?
I think we've talked about this that the implementation of a component promise failure failing the whole auction is not perfect. Is there a plan to change that? I guess no, if that's the case, we'd be better to make the spec match the impl.

[morlovich]

Right, but the server response promise can fail in a subcomponent, too.

[qingxinwu]

It seems component auction server response promise only fail a single component auction, not the whole auction (if I read https://crsrc.org/c/content/browser/interest_group/interest_group_auction.cc;drc=f522344e45882da4c7f7cb1b3a0a7bd747d654bb;l=5760 correctly, although not fully sure).

[morlovich]

So this is messy. Failing high-level parsing on it fails just the component auction, but failing type conversion to uint8array or promise rejecting aborts the entire thing:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/ad_auction/navigator_auction.cc;drc=f522344e45882da4c7f7cb1b3a0a7bd747d654bb;l=3245

[qingxinwu]

ah interesting. I think it would be better to make it consistent for this single promise? If so, failing the component auction only? @brusshamilton FYI as well

[brusshamilton]

Yes, it probably should just fail the component auction.

[qingxinwu]

ok, (1) I changed it to check [=recursively wait until configuration input promises resolve=] first so that any (non server response) promise failure could fail the whole auction which meets our implementation (the impl's behaviour is not ideal but it's not easy to change and there's no plan to change it yet).
(2) For server response promise, I kept the behaviour of only fail the component auction no matter what was the failure (promise reject, resovled promise parse failure, etc,). It's different from our impl since promise reject fails the whole auction, but we do have a plan to change the impl and it feels doable. We can change the spec later if the plan changes.