fix: drop retry_of for RP 26 implicit retry grouping - #18
Conversation
Signed-off-by: Silvia Tarabova <starabov@redhat.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughRerun handling now uses ReportPortal 26 implicit grouping by ChangesRetry grouping
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change switches retry grouping to Report Portal's implicit behavior and removes explicit retry linkage. No actionable merge-blocking risk remains; the PR is merge-ready after normal checks and review. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Fix broken retry display in Report Portal v26.0.3. After upgrading from RP v25.2, retried tests appeared as duplicate entries instead of being grouped under a single test with retries.
Root Cause
RP 26.0.3 removed the
handle_retrySQL function and moved retry handling to application-level code (reportportal/migrations#413). The new implicit mode groups retries by matchinguniqueIdandparentIdautomatically.The old approach used explicit
retry_of=original_idto chain retries back to the first attempt. This broke in RP 26 because:retry_of)retry_of=original_id→ original is already demoted (retry_of IS NOT NULL), so RP falls back to implicit modeChanges
retry_ofparameter from allstart_test_casecalls in_create_failed_attemptsoriginal_idtracking (no longer needed)retry=case_result.reruns > 0withoutretry_ofuniqueId+parentIdmatchingSummary by CodeRabbit