Suppress fabricated empty Prebid bidder params

[prk-Jr]

Summary

Stacked on #899 (feat/ssat-render-inline-creative) — base branch is that PR's head, not main.

A configured Prebid bidder with no inline params and no matching bid-param override was expanded into "bidder": {} in the OpenRTB request. PBS rejects an empty bidder object, surfacing as the intermittent auction error.

Fix

In to_openrtb (crates/trusted-server-core/src/integrations/prebid.rs):

• Track the bidders the publisher explicitly supplied (including an explicit empty {}).
• Reorder to: build bidder map → apply overrides → drop fabricated empties → decide stored-request.
• Drop any bidder still an empty object after overrides unless it was explicitly supplied.
• Recompute the PBS stored-request fallback after the drop, so a slot whose configured bidders all resolve to fabricated empties falls back to the stored-request/no-bid path instead of shipping invalid bidder objects.

Behavior contract:

• Absent bidder → dropped (never "bidder": {}).
• Publisher-supplied {} → preserved (misconfiguration stays visible).
• Bidder populated by a global/zone override → kept.
• Valid bidders still ship even when a sibling has no params.
• No eligible bidders → stored-request fallback.

The browser half of this defense (prevBidderParams retention on refresh) already shipped; this completes the server half.

Tests

New unit tests in prebid.rs:

• to_openrtb_drops_fabricated_empty_bidder_params
• to_openrtb_preserves_an_explicitly_empty_bidder
• to_openrtb_keeps_a_fabricated_bidder_that_an_override_populates
• to_openrtb_falls_back_to_stored_request_when_all_bidders_are_fabricated_empty

Verification

• cargo fmt --all -- --check ✓
• cargo clippy-fastly ✓
• cargo test-fastly ✓ (1628 core + 99 fastly, 0 failed)
• Other adapters (axum/cloudflare/spin) + clippy variants left to CI.

Test plan

• CI green across all adapters
• Manual: slot with a configured bidder lacking params no longer emits "bidder": {} to PBS

[ChristianPavilonis]

Review Summary

Approved with one non-blocking medium-severity finding documented inline. The primary fabricated-empty suppression, override ordering, and stored-request fallback behavior are covered by focused tests.

Please address the inline mixed-representation precedence case in follow-up work before relying on this path for clients that can send both direct bidder params and trustedServer.bidderParams.

[aram356]

Summary

The fabricated-empty suppression, override ordering, stored-request fallback, and focused tests are otherwise sound, but mixed bidder representations can still recreate the invalid empty bidder object nondeterministically.

Blocking

🔧 wrench

• Mixed bidder representations have nondeterministic precedence: direct bidder params can be overwritten by a fabricated empty object depending on HashMap iteration order (crates/trusted-server-core/src/integrations/prebid.rs:1440).

CI Status

• GitHub integration checks: PASS (4/4)
• fmt: PASS locally
• focused native core tests: PASS (44/44)
• Fastly test runtime: BLOCKED locally by unavailable macOS certificate keychain after successful compilation
• clippy-fastly: BLOCKED locally by a build-script tooling error (Unrecognized option: 'p')
• JS tests: not run; no JS/TS files changed

[aram356]

Summary

The or_insert fix in bfea103d9 does resolve the case flagged in the previous round — I confirmed the new 64-iteration test genuinely fails against the old extend and passes now. The reordering (build → override → drop → decide stored-request) is sound, and tracing the history shows this PR is finishing a migration #680 already intended rather than inventing a new policy: e06af4b0f abandoned "fill config.bidders with empty {}" in favour of the stored-request path a year ago, and that intent only leaked because expand_trusted_server_bidders fabricates the same empties one layer up. That evidence retired my initial concern that broadening the fallback was risky.

What holds the PR up is that the fix is one-directional, and that the central design choice re-creates the payload the PR exists to eliminate. PBS cannot distinguish a fabricated {} from an explicitly supplied one — they are identical bytes on the wire — so preserving explicit empties keeps emitting "bidder": {} through the primary shipped JS path, and parse_response turns the resulting PBS rejection into an auction-wide bid wipeout rather than a visible misconfiguration signal.

Blocking

🔧 wrench

• Preserving an explicit {} still ships the payload PBS rejects: provenance is invisible to PBS; reachable via the normal Prebid adapter path (params: {} → bidderParams: {kargo: {}}), and a PBS non-2xx zeroes every slot in the auction, not just the offending imp (prebid.rs:1480-1483, prebid.rs:2157-2166).
• The merge is asymmetric — an empty direct entry still wins over real params: the direct branch keeps an unconditional insert, so a direct {} deterministically discards trustedServer-supplied params and emits "bidder": {"kargo": {}} (prebid.rs:1453).

❓ question

• The premise underpinning the whole design is unverified in-repo: there is no test, fixture, or PBS mock anywhere backing either "PBS rejects "bidder": {}" or "an unknown stored-request ID yields a per-imp no-bid rather than a request-wide 400". Both exist only as prose in comments and commit messages. If a stored-request miss is in fact a 400, this trades one whole-auction failure mode for another instead of fixing it. Related: auction/endpoints.rs:60-63 already requires a stored request to exist for every slot code that omits inline params, and this PR widens that set to include all-fabricated-empty slots — operators with config.bidders set but no stored requests provisioned move from one broken state to another. Has the empty-bidder rejection been confirmed against the deployed PBS?

Non-blocking

🤔 thinking

• The new "cannot fire" comment is inaccurate: real inline params for a bidder outside config.bidders do fall back to the stored request, silently dropping those params (prebid.rs:1490-1493).
• Non-object params bypass the drop: null params ship as "bidder": {"kargo": null}; #[serde(default)] on BidConfig.params makes this reachable from a POST that omits params (prebid.rs:1481).

♻️ refactor

• Extract an is_empty_object helper: the emptiness predicate is inlined in the retain at prebid.rs:1481 and is needed again by both suggested fixes above. A shared fn is_empty_object(params: &Json) -> bool { params.as_object().is_some_and(serde_json::Map::is_empty) } keeps the rule in one place.

📌 out of scope

• zone leaks into every bidder's params: when a trustedServer entry has no bidderParams, expand_trusted_server_bidders (prebid.rs:942-957) hands each configured bidder the entire trustedServer object as its params, so a zone-only slot ships {"kargo": {"zone": "header"}, "triplelift": {"zone": "header"}} — a TS-internal orchestration key sent to PBS as a bidder param. These are non-empty, so the new drop never catches them; it's the third route by which fabricated params reach PBS. Pre-existing and not this PR's job, but it limits the "fabricated params never ship" contract and is worth a follow-up issue.

CI Status

• GitHub checks: PASS (4/4)
• fmt: PASS (verified locally)
• clippy (trusted-server-core, native host, -D warnings): PASS (verified locally)
• rust tests (trusted-server-core, native host): PASS (1631/1631, verified locally)
• js tests: not run — no JS/TS files changed

Note: #899 is still open, so this stays stacked and cannot merge first.