You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
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
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.
Publish the storage release that matches b4. The b4 notes mention "reporting-storage: one storage decision with versioned migrations".
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.
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).
Verified fixed with the published adcp==10.0.0b8 + adcp-reporting-storage[pg]==0.2.0b1:
tests/conformance/reporting/test_reporting_storage_published_upgrade_pg.py from next run against those installed wheels: 11 passed, 1 skipped (the b4 pairing, by design). This includes a ledger seeded by adcp==9.3.1 + 0.1.0b4 (our production pair) upgraded in place by create_schema().
Our full integration suite on that pair, including the reliable-reporting lifecycle, soak and ledger-ownership tests: 3358 passed, 0 failed.
Closing. The remaining rolling-deploy concern (older pods still running after the upgrade) is in a separate issue.
Activity
fix(reporting-storage): upgrade 0.1.0b4/0.2.0b0 ledgers in place and …
fix(reporting): refuse an adcp-reporting-storage of another storage c…
ci(release): gate publishes on a companion the built distribution wor…
fix(reporting): refuse an adcp-reporting-storage of another storage c…
fix(reporting-storage): upgrade 0.1.0b4/0.2.0b0 ledgers in place and …
fix(reporting): refuse an adcp-reporting-storage of another storage c…
ci(release): gate publishes on a companion the built distribution wor…
fix(reporting-storage): upgrade 0.1.0b4/0.2.0b0 ledgers in place and …
bokelley commentedon Nov 3, 2026
Verified fixed with the published
adcp==10.0.0b8+adcp-reporting-storage[pg]==0.2.0b1:tests/conformance/reporting/test_reporting_storage_published_upgrade_pg.pyfromnextrun against those installed wheels: 11 passed, 1 skipped (the b4 pairing, by design). This includes a ledger seeded byadcp==9.3.1+0.1.0b4(our production pair) upgraded in place bycreate_schema().Closing. The remaining rolling-deploy concern (older pods still running after the upgrade) is in a separate issue.
bokelley commentedon Nov 3, 2026
The rolling-deploy follow-up is #1831.