@Gargron Seems you want to plug Mastodon on an uncatched exception catcher… Sentry is litteraly crippled with such error from Mastodon…
And worse since last 3.1.3 release… 😱

@aeris Yeah, don’t do that. We use exceptions purposefully. The sidekiq retry mechanism works this way. Your sentry will bee overloaded. The only thing that looks alarming from the screenshot are the ENOENTs, those are trouble, everything else is business as usual

@aeris Make sure you haven’t accidentally upgraded paperclip to the latest version... Use Gemfile.lock we provide without changing it

@Gargron Ok, change it to integrate sentry, will downgrade paperclip to see if ENOENT fixed.
I use sentry at the moment because tracking https://github.com/tootsuite/mastodon/issues/12445

@aeris Mastodon keeps track of inaccessible servers to avoid delivering to them, but it has to be really sure, because you wouldn’t believe how often servers go down for short periods of time only to come back again

The class responsible for this is DeliveryFailureTracker

@Gargron Here we speak about 1 year down instance without any up period (and will never re-up, instance was completely destroyed 1 year ago)

@Gargron At least the reported instance is down since

2019-11-22T11:01:35.138Z 13569 TID-owys3wnyh WARN: Stoplight::Error::RedLight: https://mastodon.tamanoir.foucry.net/inbox

@Gargron And this instance was more likely destroyed in august 2018
https://web.archive.org/web/2018*/https://mastodon.tamanoir.foucry.net

@aeris @Gargron If you already know the server is gone, you can register the URL of the shared_inbox with the DeliveryFailureTracker.

bin/rails c

Redis.current.sadd('unavailable_inboxes', 'https://mastodon.tamanoir.foucry.net/inbox')

Since it is stored in Redis, you will need to maintain a database in redis.

By registering the inboxes of users belonging to that server, you can also deter deliveries such as follow requests. This happens with follow imports.