Iterate on Sentry filtering

[m-vdb]

Proposed changes:

• Ignore pymongo connection errors (sentry/1939788804)
• Raise MarkdownException when Markdown cannot be read (sentry/1953580685)
• Ignore CancelledError (sentry/1966753788)
• Do not load endpoint config if it is None (sentry/1946541728)
• Raise InvalidEntityFormatException when entities cannot be parsed, and ignore it (sentry/1945365040)
• Ignore MemoryError (sentry/2009040566)
• Ignore psycopg2.OperationalError (sentry/2009384160)
• Ignore botocore.NoCrendentialsError (sentry/2005727807)
• Ensure classes using class_from_module_path() are in fact classes (sentry/1952538184/071b08fc49494d3b96c16d0ed19b9913 ⚠️ there are various issues under this sentry issue, I'm addressing one type)
• Ignore Pika connection errors (sentry/2071539640)

Status (please check what you already did):

• added some tests for the functionality
• updated the documentation
• updated the changelog (please check changelog for instructions)
• reformat files using black (please check Readme for instructions)

[m-vdb]

There are some issues coming up today into Sentry (1958583765, 1952538184, 1962256159, 1951854941, 1956288097, 1946342362) that come from schema validation issues of config / domain files. While exploring solutions, I've hit a roadblock with pykwalify (the lib we use to validate yaml against a schema), especially on the slot types definition: with this lib, it's not possible to validate an object against an union of schema ("any of" use case). I don't think it's the main limitation that we have today, would be happy to hear some feedback on this point.

To me the impact is at different levels:

• At the user level: the code fails with an exception, not telling the user what the problem is. They might even think that rasa is broken
• At the rasa engineer level: hard to pin-point the initial issue when supporting a user on the forum, noise in Sentry.

I've found an alternative, cerberus which seem to support all of our use cases and seems a bit more advance at first sight.

[m-vdb]

@tmbo could I get your feedback on this one? Nothing urgent and it should be quick for you I think ^^ (tests + changelog fragments are obviously missing for the draft)

[tmbo]

thanks a lot for digging into these issues 🚀 left some thoughts

[wochinge]

Great iteration! Waiting for the approval due to my comment about Rasa X implications.

[m-vdb]

@wochinge thanks for all your review comments 💯 I think I addressed all your comments and there is this remaining open question before this can be merged

[wochinge]

Thanks for improving the reporting and doing some maintenance work at the same time 💯

[wochinge]

technically also a TypeError in case import_module fails

[m-vdb]

not sure I follow 🤔 doesn't it raise a ModuleNotFoundError which inherits ImportError?

[wochinge]

import_module in 3.8.6 also raises a TypeError which inherits from Exception

def import_module(name, package=None):
    """Import a module.

    The 'package' argument is required when performing a relative import. It
    specifies the package to use as the anchor point from which to resolve the
    relative import to an absolute import.

    """
    level = 0
    if name.startswith('.'):
        if not package:
            msg = ("the 'package' argument is required to perform a relative "
                   "import for {!r}")
            raise TypeError(msg.format(name))
        for character in name:
            if character != '.':
                break
            level += 1
    return _bootstrap._gcd_import(name[level:], package, level)

[m-vdb]

🤔 yeah ok. It sounds a bit more like a detail. Fine if I keep it like it is?

[wochinge]

It would be more transparent for the caller as they'd know which errors to handle without having to dive deeper into the code, but up to you as it's a detail as you said.

[m-vdb]

finallyyyyyyyyyyy merged!