1
0
mirror of https://github.com/TeamNewPipe/CrashReportImporter synced 2025-10-06 08:32:39 +02:00
Files

156 lines
4.3 KiB
Python
Raw Permalink Normal View History

Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
import asyncio
import functools
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
import os
2021-01-29 17:34:56 +01:00
from datetime import datetime
from smtplib import LMTP
2016-12-08 03:17:09 +01:00
import click
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
import sentry_sdk
from sentry_sdk.integrations.asyncio import AsyncioIntegration
2020-01-04 00:04:48 +01:00
from newpipe_crash_report_importer.lmtp_server import CustomLMTP
from . import (
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
DatabaseEntry,
DirectoryStorage,
GlitchtipStorage,
2021-01-29 17:14:19 +01:00
GlitchtipError,
AlreadyStoredError,
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
CrashReportHandler,
Message,
2021-01-29 16:58:55 +01:00
make_logger,
configure_logging,
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
)
2020-01-04 00:04:48 +01:00
2016-12-08 03:17:09 +01:00
2021-01-29 16:58:55 +01:00
logger = make_logger("cli")
class UnknownPackageError(RuntimeError):
pass
@click.group()
2021-01-29 17:58:08 +01:00
@click.option("--force-colors", type=bool, default=False)
def cli(force_colors):
"""
Placeholder. Allows integration the subcommands.
"""
2021-01-29 17:58:08 +01:00
configure_logging(force_colors=force_colors)
@cli.command()
@click.option("--host", type=str, default="::1")
@click.option("--port", type=int, default=8025)
def serve(host, port):
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
# report errors in the importer to GlitchTip, too
own_dsn = os.environ["OWN_DSN"]
print(f"Reporting own errors to Sentry DSN {own_dsn}")
sentry_sdk.init(
dsn=own_dsn,
debug=os.environ.get("DEBUG_SENTRY_SDK", False),
integrations=[
AsyncioIntegration()
],
)
2016-12-08 03:17:09 +01:00
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
# initialize storages
2016-12-08 03:17:09 +01:00
directory_storage = DirectoryStorage("mails")
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
newpipe_dsn = os.environ["NEWPIPE_DSN"]
newpipe_legacy_dsn = os.environ["NEWPIPE_LEGACY_DSN"]
2016-12-08 03:17:09 +01:00
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
sentry_storage = GlitchtipStorage(newpipe_dsn, "org.schabi.newpipe")
legacy_storage = GlitchtipStorage(newpipe_legacy_dsn, "org.schabi.newpipelegacy")
2016-12-08 03:17:09 +01:00
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
# define handler code as closure
# TODO: this is not very elegant, should be refactored
async def handle_received_mail(message: Message):
2021-01-29 16:58:55 +01:00
logger.info(f"Handling mail")
2016-12-08 03:17:09 +01:00
try:
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
entry = DatabaseEntry(message)
except:
logger.exception("Error while parsing the message")
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
return
2025-01-01 01:09:28 +01:00
logger.info(f"Entry date: {entry.date}")
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
if entry.date.timestamp() > datetime.now().timestamp():
logger.error("Exception occured in the future... How could that happen?")
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
return
try:
await directory_storage.save(entry)
except AlreadyStoredError:
logger.warning("Already stored in directory storage, skipping")
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
package = entry.newpipe_exception_info["package"]
2021-01-29 17:14:19 +01:00
try:
if package == "org.schabi.newpipe":
await sentry_storage.save(entry)
elif package == "org.schabi.newpipelegacy":
await legacy_storage.save(entry)
else:
raise UnknownPackageError("Unknown package: " + package)
2021-01-29 17:14:19 +01:00
except AlreadyStoredError:
logger.warning("Already stored in GlitchTip storage, skipping")
2021-01-29 17:14:19 +01:00
except GlitchtipError as e:
logger.error("Failed to store error in GlitchTip: %s", e)
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
handler = CrashReportHandler(handle_received_mail)
loop = asyncio.new_event_loop()
loop.run_until_complete(
loop.create_server(
functools.partial(
CustomLMTP,
handler,
ident="NewPipe crash report importer",
enable_SMTPUTF8=True,
),
host=host,
port=port,
)
Rewrite most of the project as an LMTP server This huge commit turns this project into an LMTP server to which Postfix can forward all mails directly. This is a lot more efficient than having the MTA send them to the MDA, save them, then fetch them via IMAP. It's a form of stream processing. It uses asyncio wherever possible to improve the parallel handling of mails and make the control flow easier than, say, having a message queue. We also have a relatively low mail volume (at most 2-3 mails per minute to this address) at the moment, so this would be overkill as well. Adding some scalability by spawning additional workers would not be too hard, though. This project now also targets GlitchTip instead of Sentry, as Sentry is non-free software now. GlitchTip is not very well documented at this point, but works quite well once you know where you need to fiddle. Unfortunately, it hardly reports errors to the user, both on the API as well as in the frontend, so one has to watch the logs a bit. Also, the Sentry docs, especially the SDK docs, don't apply 100% to GlitchTip. The rewrite further slightly improves the parsing of the stacktraces, making them look a lot more useful in GlitchTip compared to the old Sentry setup, and improving the bug aggregation a lot. A lot of research and trial and error went into this, but after importing the last 30 days worth of mail into the system with a little Python script, it seems a lot better than before. A lot of the parsing is still basically the old code, maybe with a little fixes and tweaks. The data representation in the GlitchTip storage has been rewritten entirely. The package was restructured to fix some of the mess, but there's still potential for improvements.
2021-01-27 17:24:29 +01:00
)
2025-01-01 15:53:03 +01:00
logger.info(f"server listening on {host}:{port}")
2016-12-08 03:17:09 +01:00
2025-01-01 15:53:03 +01:00
loop.run_forever()
# note that import is a protected keyword, so we have to specify the command name explicitly
@cli.command("import")
@click.argument("filenames", type=click.Path(exists=True), nargs=-1)
@click.option("--host", type=str, default="::1")
@click.option("--port", type=int, default=8025)
def import_rfc822(filenames, host, port):
logger.info(f"Connecting to LMTP server {host}:{port}")
client = LMTP(host=host, port=port)
for filename in filenames:
try:
with open(filename) as f:
data = f.read()
except UnicodeDecodeError:
logger.exception("Failed to decode mail contents, skipping")
try:
logger.info(f"Importing RFC822 e-mail file {filename}")
client.sendmail("a@b.cde", ["crashreport@newpipe.net"], data)
except KeyboardInterrupt:
logger.error("SIGINT received, exiting")
return 1
except:
logger.exception("Error while trying to import RFC822 e-mail")
if __name__ == "__main__":
cli()