+1 to removing it. PolarisMetricsManager never did anything on its own, just forwarded to callCtx.getMetricsPersistence() iiuc. createCatalog needs to write the catalog and its admin role's grant together, createPrincipal needs to write the principal and its secrets together, that's why grants and secrets stay on the manager. A metrics write never needed that, so it never belonged on PolarisMetaStoreManager in the first place.
Yufei, on the event framework point, my bias would be that's a reason to land this now rather than wait if found needed. -ej On Tue, Jun 16, 2026 at 3:40 PM Yufei Gu <[email protected]> wrote: > Hi Dmitri, > > I'm OK with making this change. > > That said, given that we seem to be converging on using the event framework > for metrics dispatching and temporary persistence, I think we will likely > end up removing metrics persistence altogether in the near future. If that > direction holds, this change may ultimately become less relevant from a > long term architecture perspective. > > That said, I don't see any issue with proceeding with the refactoring now. > > Yufei > > > On Mon, Jun 15, 2026 at 7:22 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi All, > > > > PR [4708] removes PolarisMetricsManager from PolarisMetaStoreManager (as > > part of a general CDI refactoring). > > > > Since this is a change to polaris-core classes, I'm sending this email > for > > awareness. Please review the specific changes in GH, if you're > interested. > > > > I propose merging on Jun 17 (hoping the PR author resolves outstanding > > comments). > > > > [4708] https://github.com/apache/polaris/pull/4708 > > > > Cheers, > > Dmitri. > > >
