Skip to content

10.0.0b4 is incompatible with adcp-reporting-storage 0.2.0b0: the ledger selects offering_id, which 0.2.0b0's tables lack #1763

Open

Description

@bokelley

adcp==10.0.0b4 with adcp-reporting-storage[pg]==0.2.0b0 (the only storage release on PyPI, Requires-Dist: adcp<11,>=9.0.0, so pip and uv accept the pair) fails at runtime. Every PostgreSQL Reliable Reporting configuration turn raises:

adcp_reporting_storage/ledger/pg.py, line 1330, in find_obligation
psycopg.errors.UndefinedColumn: column "offering_id" does not exist

The SDK logs it only as Reliable Reporting worker component configuration failed, so no revision is ever produced. A restart does not rebind stored generations either.

Cause

adcp_reporting_storage/ledger/pg.py imports _OBLIGATION_COLUMNS (and the generation column list) from adcp.reporting.ledger._record_rows. 10.0.0b4 added offering_id to those lists, but 0.2.0b0's reporting_ledger.sql creates reporting_obligations without the column.

import importlib.resources

from adcp.reporting.ledger._record_rows import _OBLIGATION_COLUMNS

ddl = (importlib.resources.files("adcp_reporting_storage.ledger") / "reporting_ledger.sql").read_text()
obligations = ddl.split("CREATE TABLE IF NOT EXISTS reporting_obligations", 1)[1].split(");", 1)[0]

print("adcp selects offering_id:", "offering_id" in _OBLIGATION_COLUMNS)    # True
print("storage creates offering_id:", "offering_id" in obligations)         # False

10.0.0b2 with the same storage release works.

Asks

  1. Publish the storage release that matches b4. The b4 notes mention "reporting-storage: one storage decision with versioned migrations".
  2. Have that release migrate an existing ledger: add offering_id to the tables that now carry it, backfilled '' as _record_rows documents for account-level generations. A seller with a production ledger (ours, created by 0.1.0b4 / 0.2.0b0) cannot recreate it.
  3. Make the incompatible pair unresolvable. For example, cap the next storage beta to the adcp betas it matches, and/or have adcp check the storage schema version at start and refuse with a clear error rather than failing every turn.

Found while evaluating 10.0.0b4 for the Scope3 embedded sales agent (our reliable-reporting lifecycle integration tests fail on b4 and pass on b2).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions