Hi Yufei, >From my POV polaris.iceberg-metrics.reporting.type is a Polaris Admin setting which controls how the server processes Iceberg Metrics received from clients.
Clients provide these metrics in a unidirectional manner. I do not think Client behaviour is materially affected by the status of metrics submission. In a way this data is similar to telemetry. Clients sent it, but need not worry about how the server processes it. Granted clients can receive and ignore errors from the /metrics endpoint. However, what benefit do clients gain from observing potential metrics persistence errors? >From a different perspective, if the server Admin changes the config from ignoring metrics (never errors) to persisting metrics, why should clients care that they might receive persistence errors after that change? Note that the only reasonable response type for metrics persistence errors under the IRC spec is 5xx, which is not actionable on the client side. With that in mind, I think Vignesh's proposal [5395] makes sense. Cheers, Dmitri. [5395] https://github.com/apache/polaris/pull/5395 On Thu, Oct 22, 2026 at 2:32 PM Yufei Gu <[email protected]> wrote: > Hi Vignesh, > > Thanks for raising this! > > Carrying over my point from the PR: > > When polaris.iceberg-metrics.reporting.type=persisting, the user has > explicitly chosen to persist metrics. Since Polaris selects only one > reporter, I think a persistence failure should fail the metrics request so > the client can observe it. The Iceberg Java client already catches and logs > metrics-endpoint errors. > > Could we remove both catches and let persistence errors propagate? > > I'm open to different thoughts on this. > > Best, > Yufei > > > On Thu, Oct 22, 2026 at 11:11 AM vignesh a <[email protected]> wrote: > > > Hi all, > > > > PR #5395 [1] is about to land, and I wanted to flag it here because it > > changes REST behaviour compared to today. > > > > With this change, POST .../metrics no longer returns a 500 when the > > persisting reporter's DB write fails. The error is logged and the > > report is dropped. Errors from other reporters still propagate through > > the handler as before, and authorization is unchanged. > > > > Iceberg Java already ignores errors from the metrics endpoint. This > > change keeps a broken metrics store from showing up as catalog 5xx > > errors. > > > > Thoughts welcome, especially if anyone relies on the current 500 > > behaviour. > > > > Thanks, > > Vignesh > > > > [1] https://github.com/apache/polaris/pull/5395 > > >
