bug(reporting): scope configuration generations and leases by account

[bokelley]

Summary

In 8.0.0-beta.15, Reliable Reporting configuration generations are keyed globally by (delivery_config_id, delivery_config_version), even though AdCP defines delivery_config_id as caller-selected and unique only within the authenticated caller and account.

This is a cross-account correctness and isolation bug for any multi-tenant seller using one in-memory or PostgreSQL ledger.

Current behavior

• ReportingConfiguration.generation_key returns tuple[str, int] without account_id.
• InMemoryReportingLedgerStore._configurations and _leases use that key.
• PgReportingLedgerStore selects, conflicts, leases, and releases configurations using only delivery_config_id and delivery_config_version.
• Status projection also builds configuration maps from the two-part key.

Two authorized accounts may validly publish daily@1. Today the second write either conflicts with the first account's immutable generation or aliases storage/lease/status behavior that should remain account-scoped.

Required behavior

Make the durable generation identity account-qualified everywhere, ideally through one typed SDK value rather than repeated tuples:

@dataclass(frozen=True)
class ReportingConfigurationGenerationKey:
    account_id: str
    delivery_config_id: str
    delivery_config_version: int

All configuration, obligation, lease, lookup, lock, status, and issue joins should use the same identity.

Acceptance criteria

• Two accounts can each store the same delivery_config_id and version with different valid configuration content.
• Reads, worker leases, releases, obligation generation, and status projection cannot cross account boundaries.
• In-memory and PostgreSQL stores have identical key semantics.
• PostgreSQL primary/unique constraints and every ON CONFLICT, WHERE, lock, and lease path include account_id.
• A migration path preserves existing reporting ledger rows and constraints for adopters already running beta.15.
• Tests exercise concurrent same-name generations across two accounts, including worker leasing and status reads.
• Public helper types discourage future code from reconstructing an incomplete tuple ad hoc.

Adopter impact

Embedded Sales Agent runs many publisher tenants and buyer accounts in one process/database. We cannot safely enable SDK-managed reporting for multiple accounts until this identity matches the protocol's account scope.

[bokelley]

Triage

Classification: Bug — cross-account isolation failure
Bucket(s): client (reporting ledger sub-system; no exact label match found in this repo)
Status: ready-for-human

What the experts said:

• code-reviewer: All five isolation failures confirmed as blockers; generation_key return-type change from tuple[str, int] to a three-field dataclass and Postgres PK migration make this a breaking fix; frozen-dataclass approach is sound and no FK cascades to drop.
• security-reviewer: Three blocker-level findings — (1) config collision causes CONFIGURATION_GENERATION_IMMUTABLE DoS or silent discard for Account B at pg.py:192; (2) lease_period_close selects without account_id filter so workers can acquire the wrong tenant's lease; (3) release_period_close WHERE clause drops account_id, allowing a worker to unblock a competing cross-account period-close. Also flags a latent residual path in _matches_obligations (store.py:870) that's not currently reachable but costs one line to close.

My take: This is a confirmed multi-tenant isolation bug with escalation-grade impact (lease hijacking across accounts, configuration DoS) blocking any multi-account deployment. The fix is breaking on two axes — generation_key public API and a live Postgres PK migration — so it warrants deliberate scoping and a migration file for beta.15 adopters before the change ships. @bokelley — flagging for your review given the breaking/security-sensitive nature.

Additional gap not in issue scope: _matches_obligations (store.py:870) should add and obligation.account_id == status.account_id as a defensive check; low-severity today but eliminates a latent cross-account status-attach path.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01QwD6QiwobXuWgmau16WaFf

---

Generated by Claude Code