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
postgres_reliable_reporting_service always builds the base ReliableReportingService, so adopters can't use a subclass #1588
ReliableReportingService.memory(...) constructs cls, so an adopter's subclass gets an in-memory service of its own type. adcp_reporting_storage.postgres_reliable_reporting_service(...) replaced ReliableReportingService.postgres(...) in 9.0.0 (#1557), and it always constructs the base ReliableReportingService:
The PostgreSQL factory can build an adopter's subclass, as memory() and the 9.0 betas' ReliableReportingService.postgres() classmethod could. For example, a service_class: type[ReliableReportingService] = ReliableReportingService keyword.
Impact
install() routes the reporting tools to the service's methods, so overriding them on a subclass is how a host translates errors and adds alerting around get_reporting_status, sync_reporting_status and get_revision_content. Without a way to pick the class, the Embedded Sales Agent copies the factory body: it builds PgReportingLedgerStore, PgReportingStagingStore and PgReportingSealStore and passes staging=, seals= and initialize_source_storage= itself. That copy silently drifts whenever the factory gains a store, for example when production= composes PgReportingProductionStore.
Found while moving the Embedded Sales Agent from 9.0.0b4 to 9.0.0. Since adcp-reporting-storage hasn't had its first release yet, this could land before 0.1.0b1 publishes.
Activity