Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reports to Sentry are silently ignored on some Tribler installations #7966

Closed
kozlovsky opened this issue Apr 12, 2024 · 0 comments · Fixed by #7967
Closed

Reports to Sentry are silently ignored on some Tribler installations #7966

kozlovsky opened this issue Apr 12, 2024 · 0 comments · Fixed by #7967
Assignees

Comments

@kozlovsky
Copy link
Collaborator

kozlovsky commented Apr 12, 2024

Recently, I discovered that when an error occurs on my machine and the Feedback dialog suggests sending the report to the Tribler developer, clicking the "SEND REPORT" button does nothing. The confirmation box with the message "Successfully sent the report! Thanks for your contribution" shows, but no errors appear on the Sentry server.

Specifying the debug=True option when calling sentry_sdk.init(...) allows me to see Sentry logs configured weirdly:

  • The log level for the sentry log was DEBUG, which is expected for the debug=True option but too verbose. Without the debug=True option, even error-level log records from the Sentry are silenced.
  • All sentry logs (debug and info level including) were additionally directed to stderr, duplicating the same log messages in stdout and stderr. The formatting of these log records in the stderr output was inconsistent with Tribler logs.

With enabled Sentry logs, the following log record appeared in stderr:

 [sentry] ERROR: Unexpected status code: 400 (body: b'{"detail":"invalid JSON data","causes":["invalid value: string \\"<>d27beecffcdb4caa9f914986dcc56828<>\\", expected an event identifier at line 1 column 8048"]}')

It allowed me to investigate the reason for the error. As it turns out, SentryScrubber produced a corrupted error report that was then rejected by the Sentry server.

SentryScrubber tries to remove sensitive information from the error report. It generates a set of sensitive strings with corresponding pseudo-random substitutes. For example, a username "John" may be replaced with the string "<foo>", and a machine name "JOHN-PC" may be replaced with the string "<bar>". Then, using regular expressions, SentryScrubber replaces corresponding substrings in all places of the error report.

As it turns out, the reason for the problem was that sometimes SentryReported decides to replace an empty string "" with the substitution "<>" and applies this replacement to all possible substrings. As a result, even elements added to the report by Sentry itself were transformed; for example, the identifier value

"d27beecffcdb4caa9f914986dcc56828"

was transformed into

"<>d27beecffcdb4caa9f914986dcc56828<>"

and all other string elements of the report were changed in the same way.

As a simple fix, SentryScrubber should stop considering empty strings as a potential target for replacement. After such a fix, with the current logic, SentryScrubber still has a chance to corrupt the report if some sensitive value accidentally matches the Sentry technical field value, but the chance of corruption becomes much lower.

As another change, it is worthwhile to configure Sentry logs in the following way:

  • They should send log messages of level WARNING and above to the regular Tribler logs so we have less chance of missing the case when sending the report to Sentry fails.
  • They should not spam Tribler logs with DEBUG-level messages.
  • They should not duplicate messages to stderr.
@kozlovsky kozlovsky self-assigned this Apr 12, 2024
kozlovsky added a commit to kozlovsky/tribler that referenced this issue Apr 12, 2024
kozlovsky added a commit to kozlovsky/tribler that referenced this issue Apr 12, 2024
kozlovsky added a commit to kozlovsky/tribler that referenced this issue Apr 12, 2024
kozlovsky added a commit to kozlovsky/tribler that referenced this issue Apr 12, 2024
kozlovsky added a commit to kozlovsky/tribler that referenced this issue Apr 12, 2024
kozlovsky added a commit to kozlovsky/tribler that referenced this issue Apr 12, 2024
kozlovsky added a commit to kozlovsky/tribler that referenced this issue Apr 12, 2024
kozlovsky added a commit to kozlovsky/tribler that referenced this issue Apr 12, 2024
kozlovsky added a commit to kozlovsky/tribler that referenced this issue Apr 18, 2024
kozlovsky added a commit to kozlovsky/tribler that referenced this issue Apr 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant