The remaining indexer parity gap still called out import-pipeline conflict resolution beyond the stored procedures already present in the data layer.
Operators could trigger conflict logging indirectly, but there was no supported HTTP or UI path to list durable source metadata conflicts or apply the existing resolve/reopen procedures from the admin console.
Design notes:
Add a stored-procedure-backed read path for source_metadata_conflict so operator tooling can review unresolved and resolved conflicts without inline SQL.
Thread conflict list, resolve, and reopen operations through the injected indexer facade and expose them under /v1/indexers/conflicts.
Extend the /indexers admin console with a compact conflict queue and resolve/reopen controls colocated with the import workflow, since that is where operators already review unmapped and duplicate import outcomes.
Test coverage summary:
Added revaer-data coverage for the new conflict list proc wrapper authorization failure.
Updated the UI route smoke test to assert the new Source conflict resolution section renders on /indexers.
Full regression gates passed with just ci and just ui-e2e.
Observability updates:
The new app-facade operations emit standard indexer.source_metadata_conflict_* metrics and latency observations through the existing run_operation instrumentation.
No additional error re-logging was introduced; propagated data errors are still translated without duplicate logs.
Risk & rollback plan:
Risk is limited to exposing a new operator control surface and a read proc over existing conflict rows.
Rollback is a straightforward revert of the new migration, HTTP handlers, and UI section if the workflow needs to be redesigned.
Dependency rationale:
No new dependencies were added.
Alternatives considered: leaving conflict resolution as a database-only operation or folding it into ad hoc import-job status text. Both were rejected because they keep operators out of a supported end-to-end workflow.