feat(reporting): Resilient composite reporters and lower memory HTML reports

[mlikasam-askui]

Summary

Improves reporting reliability when a single reporter fails, and reduces memory use for large HTML reports that include many screenshots.

Changes

• ReporterErrorHandler: Wraps a Reporter, catches exceptions from add_message, add_usage_summary, add_cache_execution_statistics, and generate(), logs with logger.exception, and stops calling the wrapped reporter after the first failure so one bad reporter does not break the rest.
• CompositeReporter: Every nested reporter is wrapped with ReporterErrorHandler.
• SimpleHtmlReporter:
  • Message rows are appended to a temporary file as they arrive instead of storing a full in-memory list.
  • generate() writes the HTML header, copies the temp file into the report, removes the temp file, and writes the footer. So base64 image data is not all held in memory at once during long runs.

[philipph-askui]

Did you test this thoroughly, i.e. with edge cases such as crashing / terminating the execution?

[philipph-askui]

what if the content block of the html changes? Then, the number of whitespaces here will be incorrect, no?

[programminx-askui]

@mlikasam-askui & @philipph-askui ,

can we finalize this PR?

[philipph-askui]

@mlikasam-askui & @philipph-askui ,

can we finalize this PR?

@programminx-askui
we are currently testing it in a project. I propose to wait with merging until we get positive feedback from there.

[philipph-askui]

We observed an issue with the tempfile during testing. The execution crashed due to a server-side timeout, but then we also got the following error:
[WinError 32] The process cannot access the file because it is being used by another process.

The reason seems to be a potential issue in SimpleHtmlReporter._get_temp_messages_file() (reporting.py:330-338).
tempfile.mkstemp() returns a tuple (fd, name), but only the file name is stored, the file descriptor is discarded via _.

On Windows the unclosed file descriptor keeps an OS-level lock on the file. When generate() later tries to delete it with self._temp_messages_file.unlink() (line 1272), Windows rejects the call with an error:
[WinError 32] The process cannot access the file because it is being used by another process.

@mlikasam-askui : can you please take care of this?
(e.g. by closing the fd right away (os.close(fd)) or by switching to tempfile.NamedTemporaryFile(delete=False) which gives a proper file handle that can be closed cleanly)