Inject MetricsPersistence directly into PersistingMetricsReporter

[bowsii]

Fixes #4655

1. Added a CDI producer for MetricsPersistence in ServiceProducers.

2. Removed CallContext dependency from PersistingMetricsReporter.

3. Removed PolarisMetaStoreManager dependency from
   PersistingMetricsReporter.

4. Injected MetricsPersistence directly into
   PersistingMetricsReporter.

5. Replaced:
   metaStoreManager.writeScanMetrics(...)
   with:
   metricsPersistence.writeScanReport(...)

6. Replaced:
   metaStoreManager.writeCommitMetrics(...)
   with:
   metricsPersistence.writeCommitReport(...)

7. Updated Javadocs to reflect direct MetricsPersistence usage.

8. Refactored PersistingMetricsReporterTest:

   • Removed CallContext mocks.
   • Removed PolarisMetaStoreManager mocks.
   • Added MetricsPersistence mock.
   • Updated verifications to use
     writeScanReport() and writeCommitReport().

Checklist

• 🛡️ Don't disclose security issues! (contact security@apache.org)
• 🔗 Clearly explained why the changes are needed, or linked related issues: Fixes #
• 🧪 Added/updated tests with good coverage, or manually tested (and explained how)
• 💡 Added comments for complex logic
• 🧾 Updated CHANGELOG.md (if needed)
• 📚 Updated documentation in site/content/in-dev/unreleased (if needed)

[dimas-b]

Thanks for the quick response on #4655 , @bowsii ! 🙂

[dimas-b]

#4655 implies avoiding indirection via CallContext 😉

Would you mind taking this one step further and removing MetricsPersistence from CallContext? I do not think there is any reason for it to be there after this PR. This producer can deal with the factory directly (cf. polarisCallContext() on line 138).

The benefit would be that MetricsPersistence would be materialized only on API calls involving metrics reporting.

If you prefer that can be done as a separate follow-up PR. Current change is good and self-contained 👍

[bowsii]

Thanks for the suggestion!

I've taken it one step further and removed MetricsPersistence from PolarisCallContext entirely. The request-scoped producer now resolves it directly from MetaStoreManagerFactory, following the same logic previously used during call context creation.

This means MetricsPersistence is only materialized for requests that actually inject it (such as metrics reporting), while non-metrics API calls no longer create or carry it in the call context.

I've also updated the affected call sites and tests accordingly.

[dimas-b]

I think we're making progress :) a few more minor comments and I think we can merge.

[dimas-b]

This code is no longer invoked, I think... why not remove it?

[dimas-b]

also not invoked, AFAIK.

[dimas-b]

Why bother calling getOrCreateSession() now? This producer will be invoked by CDI only for use cases that need a MetricsPersistence, not BasePersistence 🤔

The old optimization of reusing the same object is no longer relevant.

I think calling getOrCreateMetricsPersistence() (below) is sufficient.

[dimas-b]

FYI: @obelix74

[bowsii]

Thanks @dimas-b!

I've addressed the remaining comments:

• Confirmed writeScanMetrics and writeCommitMetrics had no callers after the refactor and removed PolarisMetricsManager entirely.

• Removed the corresponding PolarisMetricsManager references and stale javadocs.

• Simplified the MetricsPersistence producer to call getOrCreateMetricsPersistence(realmContext) directly.

• Verified with:

  • ./gradlew format
  • ./gradlew :polaris-core:check
  • ./gradlew :polaris-runtime-service:test --tests "org.apache.polaris.service.reporting.PersistingMetricsReporterTest"

Please take another look when you have a chance.