eidCache: add merging targeting responses to core - #330
eidCache: add merging targeting responses to core#330etiennelatendresse-optable wants to merge 1 commit into
Conversation
fe6955b to
7f669a0
Compare
etiennelatendresse-optable
changed the title
7f669a0 to
f78596d
Compare
f78596d to
7887dbe
Compare
| }>; | ||
| // UID2 refresh material resolved from the response refs map. Cache-only: | ||
| // the RTD module strips it before EIDs reach bid requests. | ||
| _ref?: Uid2RefData; |
There was a problem hiding this comment.
Before this lands: the comment on _ref says "the RTD module strips it before EIDs reach bid requests." RTD isn't the only egress. shemedia and pmc have been leaking UID2 refresh_token into bid requests since 2026-08-25 via pubProvidedId, which never touches RTD. chess hit the same bug and fixed it locally in Optable/optable-solutions#774 the day before.
There are now three strippers for this one field (rtd.ts, stripSidecars in #331, cleanEid in the wrappers), each covering a different subset. Every new egress is a leak until someone adds a fourth.
Suggestion: keep refresh material off the EID, in a sidecar keyed by source.
refs?: Record<string, Uid2RefData>; // keyed by eid.sourceresolveRefs writes refs[eid.source]; getRefData, isUid2Stale and uid2-refresh look up by source. Cached EIDs then are wire EIDs, nothing needs stripping, and mergeCache can drop uids[].ext.optable.ref too. Migration is one release of read-side fallback for caches that still have _ref.
Happy to push it onto the branch.
There was a problem hiding this comment.
I agree with MO that RTD is not the only reader of this. I am not against the refs structure if it will help us moving forward. But the way we solutionize this code already we populate _ref, so the migration path might be trickier. But if we decide this is fine we can work that our
3 participants
Why
Cache-merge logic could be moved to a core reusable function.
What Changed
mergeCache,resolveRefs,getRefData,isUid2staleHow to Test
Notes