Thanks, Vignesh. In that case, I think we should monitor the metrics endpoint separately and exclude it from the core catalog availability SLO. A metrics storage failure shouldn't imply that table operations are unavailable.
Returning 500 is the correct server-side behavior when metrics persistence fails. Whether to retry, log the failure, or ignore it is up to the client. I'd prefer to address the SLO concern in monitoring rather than return success for a failed request. Yufei On Sat, Oct 24, 2026 at 11:46 AM vignesh a <[email protected]> wrote: > Hi Yufei, > > Thanks for following up. I see the point: if Iceberg already ignores > errors from the metrics POST, a Polaris 500 often won't fail the job, > and it can still tell an operator that the persist failed. > > What I'm trying to avoid is Polaris itself counting that as a catalog > 5xx (in SLOs, or anything that treats POST .../metrics failures as the > catalog being down) when an admin turns persisting on and the metrics > table is unhealthy. > > We still log the failed write at WARN, so that signal stays on the > server. If you'd rather keep the 500 for operator visibility, I'd like > to understand that use case better. > > Thanks, > Vignesh >
