GAM derived sync streams report critical never_run when scheduler marks them inapplicable

[bokelley]

Derived GAM sync streams report critical never_run for inapplicable tenants

Summary

The GAM-derived sync streams signal_coverage and pricing_availability can remain critical / never_run forever for tenants that the scheduler intentionally excludes as inapplicable.

This creates a false operational blocker in Interchange storefront status and downstream composition flows. We manually forced both streams for one affected production tenant to clear the immediate incident, but the root mismatch still appears present in the deployed salesagent image.

Production evidence

Affected customer incident:

• Customer: Scope3 (1800)
• Storefront: Wonderstruck
• GAM network: 23312659540
• Salesagent tenant: tenant_0cf4d380

Manual force run performed on 2026-06-09:

• signal_coverage: sync_a7e0378d656b45d8, completed successfully
  • counts: signals_seen=0, keys_queried=0, signals_updated=0
• pricing_availability: sync_80dc2fd1ad784db0, completed successfully
  • counts: products_seen=6, products_with_placements=0, products_updated=0, placement_ids_queried=0

The manual runs were no-op data updates, but they cleared the never_run health state for this tenant.

Tested deployed image

After a later salesagent redeploy, I tested prod image:

us-central1-docker.pkg.dev/swift-catfish-337215/scope3/agentic-embedded-salesagent:14f8137ab013d1bf24dddd593b40a6a5c20fcf5a

The issue still reproduces on a clean same-network tenant:

• Tenant: tenant_a15f79ad
• GAM network: 23312659540
• Existing rows for signal_coverage / pricing_availability: 0
• Status result:
  • signal_coverage.status=never_run, severity=critical
  • pricing_availability.status=never_run, severity=critical

What appears to be happening

The schedulers correctly skip tenants that do not have applicable source data:

• gam_signal_coverage_scheduler._list_eligible_tenants

  • only includes GAM tenants where _tenant_has_custom_key_value_signals(...) is true
  • Wonderstruck has no mapped custom_key_value signals

• gam_pricing_availability_scheduler._list_eligible_tenants

  • only includes GAM tenants where _tenant_has_priced_placements(...) is true
  • _tenant_has_priced_placements only checks effective_implementation_config["targeted_placement_ids"]
  • Wonderstruck products use targeted_ad_unit_ids, not targeted_placement_ids

But tenant_status_service._syncs_block emits both streams unconditionally, and sync_health.derive_sync_health maps an empty run list to _never_run_health(...), which becomes critical after the grace window.

So the scheduler says "not applicable, skip", while status says "critical, never run".

Expected behavior

For inapplicable derived streams, tenant status should not report critical / never_run.

Preferred:

• Add an explicit not_applicable status/severity contract for sync blocks, or
• Return success / ok with item count 0 and a clear summary for inapplicable streams.

At minimum:

• signal_coverage should be non-critical when the tenant has no mapped custom-key signals.
• pricing_availability should be non-critical when the tenant has no supported product targeting inputs.

Related pricing availability gap

Wonderstruck products target GAM ad units:

targeted_ad_unit_ids: present
targeted_placement_ids: absent

The current pricing/availability eligibility and report path appear placement-only. Please either:

• extend pricing/availability guidance to support targeted_ad_unit_ids, or
• explicitly classify ad-unit-only tenants as not applicable until that support exists.

Suggested fix

1. Add applicability checks to status derivation for signal_coverage and pricing_availability.
2. Avoid surfacing "retry_sync" for streams that the scheduler will never enqueue.
3. Add regression coverage for:
   • GAM tenant with no custom-key signals -> signal_coverage is not critical.
   • GAM tenant with ad-unit-only products and no placements -> pricing_availability is not critical, or the sync supports ad units and becomes eligible.
   • Existing applicable tenants still become eligible and stale/failed states still surface correctly.

Why this matters

Interchange storefront health currently treats these critical never_run blocks as setup/composition blockers. That caused product discovery/composition to fail for Wonderstruck until we manually wrote no-op sync rows.