mark qrep failure in db and filter out of result

[jgao54]

When a QRep workflow fails (for example a snapshot clone during a CDC initial load or a table addition), its peerdb_stats.qrep_runs row keeps consolidate_complete = false. InitialLoadSummary reports it as in progress forever, and a retried attempt for the same table adds a second row, so the UI shows a table with more than one in-progress run.

Changes:

• Add a failed boolean column to peerdb_stats.qrep_runs
• QRepFlowWorkflow now runs a MarkQRepRunFailed activity when it returns an error
• InitialLoadSummary filters out failed runs, so only completed and in-progress runs reach the UI.
• Failed rows and their partitions stay in the catalog, so the history of failed attempts is preserved for debugging.

Testing:

• add integration test
• verified peerdb UI and db locally

Fixes: DBI-1105

[github-actions]

❌ Test Failure

Analysis: Not flaky: the PR's new test Test_QRep_Retry_Sweeps_Unfinished_Run fails identically and instantly on all three matrix legs with a "duplicate key value violates unique constraint flows_name_unique" error, indicating the test/code creates the same QRep flow name twice; a separate pg18-only snapshot timeout is likely a genuine flake but is not the run-blocking failure.
Confidence: 0.92

⚠️ This appears to be a real bug - manual intervention needed

View workflow run

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

[ilidemi]

This approach is generic but makes it a bit harder to match the misbehaving area with the error handling for it.
Wdyt of this approach:

• separate the first monitoring.InitializeQRepRun into its own activity right before GetQRepPartitions
• put this defer after it

[jgao54]

good point

[jgao54]

done, also separated out monitoring.InitializeQRepRun into RecordQRepRun and RecordQRepPartitions because the txn there for both tables was deceiving anyways as the second insert into qrep_runs is a no-op and that was always bothering me. Now it is more explicit.