fix(report): remove Sentry capture for empty report uploads

[drazisil-codecov]

Summary

Improves error messaging for empty report uploads and removes unnecessary Sentry noise.

Changes

1. Remove Sentry capture for ReportEmptyError

Empty reports are expected user behavior (e.g., no coverage data in upload). This was generating ~480K unnecessary Sentry events per month.

2. Track which files were empty

When processing an upload with multiple coverage files, we now track which files:

• Had no contents
• Processed but resulted in no coverage data

3. Include empty file names in error message and logs

Before:

ReportEmptyError: No files found in report.

After:

ReportEmptyError: No coverage data extracted. 3 of 20 file(s) were empty: coverage1.xml, coverage2.xml, coverage3.xml

The log warning now also includes:

• empty_files: list of up to 10 empty file names
• empty_files_count: total count of empty files
• total_files_count: total files in upload

Why This Matters

When a user uploads 20 coverage files and 3 are empty causing the upload to fail, they can now see WHICH files were the problem instead of searching through thousands of lines.

Impact

• Fixes WORKER-WH2: ~480K events/month
• Better debugging experience for users with empty uploads

---

Note

Improves handling and observability of empty coverage uploads while reducing noise.

• Enhances ReportEmptyError to include empty_files and total_files, with clearer, contextual messages
• process_raw_upload now tracks files with no contents or no extracted coverage and raises ReportEmptyError with details
• Updates logging in report processing to include empty_files (truncated), empty_files_count, and total_files_count; removes Sentry capture for ReportEmptyError
• Adds unit tests for new error messaging and processing behavior

^{Written by Cursor Bugbot for commit 8199a1e. This will update automatically on new commits. Configure here.}

[sentry]

Codecov Report

❌ Patch coverage is 95.45455% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 93.35%. Comparing base (6e3603b) to head (8199a1e).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
apps/worker/helpers/exceptions.py	90.90%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #653      +/-   ##
==========================================
- Coverage   93.35%   93.35%   -0.01%     
==========================================
  Files        1292     1292              
  Lines       47128    47143      +15     
  Branches     1567     1567              
==========================================
+ Hits        43996    44010      +14     
- Misses       2823     2824       +1     
  Partials      309      309              

Flag	Coverage Δ
workerintegration	59.11% <36.36%> (-0.03%)	⬇️
workerunit	91.26% <95.45%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[drazisil-codecov]

@sentry review

[codecov-notifications]

Codecov Report

❌ Patch coverage is 95.45455% with 1 line in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
apps/worker/helpers/exceptions.py	90.90%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[adrianviquez]

What's the criteria for us not doing coverage data if there are more than 5 files?

[adrianviquez]

why is this no longer e.reportid?

[drazisil-codecov]

Addressing the review feedback:

Re: "What's the criteria for us not doing coverage data if there are more than 5 files?"

The limit of 5 file names in the error message is purely a UX decision to prevent excessively long error messages. The actual coverage processing isn't affected - we still process all files. We just truncate the display of empty file names in the error message to keep it readable. The full count is still shown (e.g., "5 of 20 file(s) were empty: file1, file2, file3, file4, file5, (and 15 more)").

The log warning includes up to 10 file names via e.empty_files[:10] for more detailed debugging.

Re: "why is this no longer e.reportid?"

We already have reportid in scope at the catch site - the old code was assigning it to the exception (e.reportid = reportid) just to read it back in the log. Using reportid directly is simpler and avoids the unnecessary indirection. The exception still has a reportid attribute for any code that catches and re-raises it elsewhere.

Re: None filenames bug (cursor[bot])

This was fixed in the second commit - lines 64-65 and 84-85 now check if current_filename: before appending to empty_files.