> 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.
+1, exactly what I am thinking. Why do we need a server side change in that case? Yufei On Thu, Oct 22, 2026 at 2:23 PM Dmitri Bourlatchkov <[email protected]> wrote: > 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 > > > > > >
