prebid
Include EIDs from user.ext.eids in 2.6 upgrade function
PR to propose we keep all the eids on 2.6 upgrade from both the 2.5 location and the 2.6 location if both exist. This may frequently happen if PBS js adapter is setting the 2.6 location and the publisher is manually writing to the 2.5 location.
This needs to be an issue for the Committee to discuss. All current upgrade paths prefer the new location if present and ignore the old location, which may also be present for compatibility.
Why would a publisher send a request with a mix of both the new location and the ext? I don't understand why the publisher doesn't just choose one. At some point, the publisher needs to be responsible for sending reasonable requests to PBS and this does not seem like a reasonable scenario.
I don't understand why the publisher doesn't just choose one.
In our case we are choosing the old location but prebid server bid adapter has chosen the new location. If we set the new location, many of our other bidders are not able to see it in JS. This is related to https://github.com/prebid/Prebid.js/pull/12110
Edit: that doesnt appear to be true, we're only setting in ext.eids and I can no longer identify a conflict, so this pr might be solving a hypothetical problem.
In our case we are choosing the old location but prebid server bid adapter has chosen the new location.
That's ok. Prebid Server will provide the correct location to the adapter, depending on if it supports OpenRTB 2.6.
I can no longer identify a conflict, so this pr might be solving a hypothetical problem.
Makes sense. In this case, shall we close this PR?
Forgot to bring this up in the PBS meeting today. Have we decided whether there's a problem here?
@patmmccann can we close this PR? Based on our discussion at the PMC yesterday, it is my understanding that PBJS will soon address the scenario where EIDs are set in both the 2.5 and 2.6 locations. I think we were in agreement that this sort of problem is best handled upstream.