Name the guard that stops an APS creative render

[jevansnyc]

Why

Investigating blank ads on a live publisher page, APS bids were winning the
auction and Ad Manager was filling the slot, yet the creative never drew. The
tester framework reported the slot as "filled" at 1x1, which is exactly what a
successful universal-creative render looks like before it resizes. Nothing
downstream distinguished the two.

Two blind spots made this close to undiagnosable from the outside:

• Every guard on the APS render path returned silently. A frame that rejected
  the descriptor, one that never received it, and one that timed out all looked
  identical: an iframe that loaded and did nothing.
• The APS capability handshake never reported to GPT diagnostics, so ts_console
  showed delivery: unknown on every request cycle and zero creative failures,
  while APS bids were rendering blank.

On the page under investigation that was 24 of 24 cycles unattributed.

What changed

The sandboxed renderer document (aps.rs) reports which guard stopped it,
on the existing failure message: bad_hash, source_mismatch,
nonce_mismatch, descriptor_keys, descriptor_fields,
descriptor_envelope, amazon_script_error.

The Universal Creative source (render.ts) labels its own frame_timeout
and frame_load_error and relays whichever reason it holds to the top window.

The GPT bridge (gpt/index.ts) records a creative attempt around the
handshake and names each silent return: aps_consumed_tombstone,
aps_source_not_in_ad_unit, aps_descriptor_fields, aps_tombstone_capacity,
aps_missing_renderer_url. A successful post records a response, so this path
reports trusted_server_response_sent rather than unknown.

Notes for review

The APS path runs on the publisher's own Prebid ad units, which never pass
through Trusted Server slot mapping. No creative opportunity exists for them, so
the store rejected the attempt as creative_request_without_slot. The bridge now
resolves the GPT slot by element ID and records the opportunity first. That is
the least obvious part of the change and the part most worth a look.

Security posture, since a reason crosses an origin boundary:

• Reasons are fixed categories. A rejected descriptor is never echoed back.
• Reporting from the frame is one-shot and answers through parent, never the
  sender, so an unrelated sender cannot consume the report or learn from it.
  Traffic not shaped like the handshake stays silent, as before.
• Relayed reasons resolve through a null-prototype allowlist, so a hostile
  __proto__, constructor, or toString resolves to undefined.
• The attempt is taken from our own tombstone, never from the message.
• The relay is recording only and never influences delivery.

This is instrumentation. It does not attempt a fix, because the root cause is
still unknown: the evidence says the handshake completes and the renderer frame
loads, then the chain dies before Amazon's prebid-creative.js is requested.
These reason codes are what will name it on the next occurrence.

Testing

• render.test.ts: relay of a frame reason, frame timeout, and the allowlist
  including inherited-key and non-string rejection
• ad_init.test.ts: creative attempt recorded for a registered APS renderer,
  and the tombstone reason on a replayed ad ID
• aps.rs: every guard reports a reason, reporting is one-shot, no descriptor
  echo, and the frame never answers the sender

Gates run: cargo fmt --check, clippy (fastly target, -D warnings),
cargo test -p trusted-server-core (2143 passed), JS build, JS format, and the
full vitest suite (850 passed).

Two caveats. The vitest suite has 27 pre-existing failures in
sourcepoint/index.test.ts and permutive/segments.test.ts, all one
localStorage error from running Node 26 against a repo pinned to 24.12.0; the
count is unchanged by this branch. And the remaining adapter gates (axum,
cloudflare, spin, parity) were not run locally, because a .cargo/config.toml
alias conflict with a stale sibling checkout meant cargo had to be invoked from
outside the repo without workspace aliases. CI covers those.

[aram356]

@aram356 Will test in staging before merging in #1019

[aram356]

@ChristianPavilonis to understand if belongs in #1019

[ChristianPavilonis]

Summary

Reviewed cb1de4777cdd5efe2a32892c03d00c1b071795f6. Requesting changes because the new reporting path can alter APS delivery and the diagnostics pipeline does not currently retain the APS failure evidence this PR introduces. Four actionable findings are posted inline.

[ChristianPavilonis]

🔧 P1: Wire the new APS reasons through the real diagnostics consumers

The runtime validator in gpt_diagnostics/store.ts:168-174 still accepts only the four original failure values, so every new aps_* reason is discarded by recordTrustedServerCreativeFailure(). The overlay switch in gpt_diagnostics/overlay.ts:185-194 also has no APS cases. As a result, ts_console and exported snapshots will continue showing no APS creative failures. The new tests mock the recorder and therefore do not exercise either consumer.

Update the store allowlist and overlay labels for every new category, make the presentation switch exhaustive, and add a test that passes an APS reason through the actual recorder/store and verifies the snapshot and overlay output.

[ChristianPavilonis]

🔧 P1: Do not let a foreign sender terminate rendering

A shaped message from a non-parent source now emits source_mismatch without a nonce. The Universal Creative wrapper accepts nonce-less failure messages from this iframe at render.ts:623, calls fail(), removes the iframe, and rejects the render. A sibling or ancestor window that obtains the iframe's WindowProxy can therefore race the valid parent message and suppress APS delivery. Previously this traffic was ignored, and the PR describes reporting as unable to influence delivery.

Keep event.source !== parent silent, or route this observation through a path that cannot trigger terminal renderer failure. Please add a test where a foreign shaped message arrives before the valid nonce-bound parent handshake and confirm the render still succeeds.

[ChristianPavilonis]

🔧 P1: Keep the attempt writable for downstream renderer failures

This marks the attempt completed as soon as port.postMessage returns. The store then clears its cycle at gpt_diagnostics/store.ts:529-531, and recordTrustedServerCreativeFailure() drops all completed attempts at line 549. Renderer timeouts, descriptor failures, Amazon script failures, and consumed-ID replays necessarily arrive after this response, so they cannot be retained even after the APS allowlist is fixed. The existing store test at store.test.ts:1707 explicitly verifies that post-completion failures are ignored.

Keep the cycle association writable for the 30-second mutation window after recording the independent response timestamp, or add a separate post-response failure channel. Cover response sent followed by a frame failure and a replay using the real diagnostics store.

[ChristianPavilonis]

🔧 P2: Do not create next-request evidence while associating the current APS attempt

This handshake occurs after the current GPT request, but recordTrustedServerOpportunity() explicitly records evidence for the slot's next request (gpt_diagnostics/store.ts:334 and :925-953). The creative attempt attaches to the latest existing cycle while this pending intent survives. A refresh within five seconds can therefore mislabel the next cycle as trusted_server_direct with a renderable candidate, or as competing when its real Prebid or publisher marker is also present.

Use a separate operation that associates the APS ad-unit code with the current GPT slot without creating next-request intent, or add an APS-specific current-cycle attempt method. Add a two-cycle test proving the following refresh receives only its own request-path evidence.