I found an unexpected use of assertion in the block of `assert_raise`
when I implemented https://github.com/rubocop/rubocop-minitest/pull/137.
It is expected to be asserted after an exception is raised in
`assert_raise` block, but in actually it is not asserted after an
exception is raised. Therefore, this PR removes or updates assertions
that have not been asserted after an exception has raised.
This PR will add `rubocop-minitest` and enable
`Minitest/UnreachableAssertion` cop to able similar auto-detection,
but will remove `rubocop-minitest` from this PR if you don't like it.
This is imperfect in situations when a separation
between regular files (such as uploads) and emails
is necessary (for the purposes of regulatory compliance,
proper compartmentalization, etc.)
Solution: allow configuring ActionMailbox's storage service
Fix that a storage upload error would leave behind a stuck-pending ActionMailbox::InboundEmail that could never be processed. The message isn't lost: the SMTP relay sees an HTTP server error and defers message delivery. We just have spurious, non-actionable InboundEmails stuck pending and tripping monitoring.
This does still leave behind an unattached ActiveStorage::Blob with no corresponding object on the storage service, but that's less annoying.
The from_address method is added to Mail::Message, but is not used
internally to ActionMailbox, nor tested (even implicitly). As it is part
of the public API, it feels important to at least have a basic test of
it.
Similarly, the x_original_to_addresses was only implicitly tested via
the recipients_addresses method. Given other similar methods are
explicitly tested, it feels like an oversight not to test it as well.
As the test introduced from_address didn't align with the naming of
RecipientsTest, I renamed it to the more generic AddressesTest.
Allow passing a block to the create_inbound_email_from_mail and
receive_inbound_email_from_mail test helper methods.
When you wanted to test a multipart email -- for example, an email that
has both a plaintext part and an HTML part -- there wasn't a way to
easily build one without a pre-made fixture. By allowing you to pass a
block to these methods, we unlock the power of Mail.new to easily
create a variety of emails, from multi-part emails, to emails with
attachments, and beyond.
Currently, the only exposed entry point into the ApplicationMailbox's configured
routing system is to call `route`, which performs a lot of work to fully
`process` inbound email. It'd be nice to have a way (e.g. in test) of checking
which mailbox an email would route to without necessarily processing it yet.
This also adds a new column, message_checksum, to the action_mailbox_inbound_emails table
for storing SHA1 digest of the email source. Additionally, it makes generating the missing
message id deterministic and adds a unique index on message_checksum and message_id to
detect duplicate emails.
Koichi ITO