Improve Behavior and Consistency of Report Processing Logic Across PR comment and App (Commit and PR)

[codecovdesign]

Problem to Solve

When report processing fails on a pull request, the failure is currently only visible in the commits section. Users may not be aware that they need to check commits for this information, leading to confusion and missed insights.

Proposed Solution

Update Codecov’s PR comment messaging to display a clear indication of report processing failures directly on the PR page.

areas for investigation:

• initial investigation:
  • why is there an error mismatch here in commit vs PR?
  • today, do we show full or partial data on the pr comment, PR app and commit app
• Next: what is our intended/desired behavior?
  • is it worthwhile to show coverage information IF any related commits contains reports that are not received?
  • do we want to show partial data or awaiting full data (intended)?
    • IF partial show some copy/indication of such
  • should afternbuilds consider as default? tradeoff is long wait
  • suggestion: show the processing/pending state and then outline error

[codecovdesign]

raised at audit, marking as bug, as pointed out per the user expectation is unexpected

[codecovdesign]

sync with Eli on 8/29

• we need to better understand the logic/engineering here. why can't we report an intermediary state or display upload count and should we push harder indicate how many uploads are processing x or y (example)? Overall, there is a lot to do but we'll probably need to expand our capability and contextualize the data for the user. route moving forward for exploration: 1) identify intermediate state, 2) default doesn't show coverage, 3) can opt-in to partial data

• Kyle todo setup a kickoff

[codecovdesign]

related issue under review here: #2442
this is related since the contextualized state there when incomplete information is show for a different but related scenario. if we'd like to show partial information, we could follow this pattern.