Proposal for Improving Error Reporting Mechanism in Sentry

[drew2a]

We have the very first Sentry issue reported by @xoriole's new mechanism for error reporting.

The great news is that it is working, and the mechanism can be improved further.

Currently, the formatting of the Event is as follows:

This links together two issues:

OSError
[WinError 1] Incorrect function: 'Z:\\Tribler\\lib\\aiohttp_apispec\\static'[<relief>-core PID:3512] 2024-06-03 00:13:38,464 - ERROR <exception_handler:141> CoreExceptionHandler.unhandled_error_observer(): Save the error to later report

and

CoreCrashedError
The Tribler core has unexpectedly finished with exit code 1 and status: 0.

The real issue with the stack trace is buried somewhere inside the event:

My proposition is that the real issue with its stack trace should be easily accessible in the report and should not be substituted by CoreCrashedError. Also, it seems that the excessive core output is captured for the issue description:

[WinError 1] Incorrect function: 'Z:\\Tribler\\lib\\aiohttp_apispec\\static'[<relief>-core PID:3512] 2024-06-03 00:13:38,464 - ERROR <exception_handler:141> CoreExceptionHandler.unhandled_error_observer(): Save the error to later report

Where the necessary part is

[WinError 1] Incorrect function: 'Z:\\Tribler\\lib\\aiohttp_apispec\\static'

and the excessive is

[<relief>-core PID:3512] 2024-06-03 00:13:38,464 - ERROR <exception_handler:141> CoreExceptionHandler.unhandled_error_observer(): Save the error to later report

Related:

• 8050

[drew2a]

Can be related to

• 8055