It will check reachability for an instance deemed unreachable at the following intervals:
4 attempts, once a minute
4 attempts, once every 15 minutes
4 attempts, once every 60 minutes
4 attempts, once every 8 hours
4 attempts, once every 24 hours
This should be effective and respectful of the resources of instances on the fediverse.
We have the Oban Pruner plugin enabled to keep the Oban Jobs table from growing indefinitely. It prunes every 15 minutes, but this will interfere with our ability to enforce uniqueness on the ReachabilityWorker jobs for a time period longer than 15 minutes. The solution is to exclude the ReachabilityWorker from the pruning operation and instead schedule a custom job that will prune the table for us once a day. The ReachabilityPruner cron task will clean up the history of the ReachabilityWorker jobs older than 6 days.
The result of Oban jobs determine the reachability status.
Publisher jobs will cancel themselves at execution time if the target server is now unreachable.
Receiving activities does not immediately mark a server as reachable, but creates a ReachabilityWorker job to validate.
A Cron will execute daily to test all unreachable servers.
- `/api/v1/accounts/:id/block` now has a "duration" parameter
- `/api/v1/blocks` returns "block_expires_at" to indicate when the block
will expire
- MuteExpireWorker also processes block expiration
- Remove unused OpenAPI parameters from mute endpoint
- Add pleroma:block_expiration to nodeinfo features
An instance block with authenticated fetch being required can cause this as we couldn't get the user to find their public key to verify the signature. Commonly observed if someone boosts/Announces a post from an instance that blocked you.
This logic only exists in the Plug, so attempting to validate the signature by calling the library function HTTPSignature.validate_conn/2 directly will never work because we do not attempt to construct the (request-target) and @request-target headers with both the commonly misinterpreted and correct implementation of this field. Therefore all attempts to validate a signature from an Oban Job will fail.
When signatures fail on incoming activities we put the job into Oban to be processed later instead of doing the user fetching and validation inline which is expensive and increases latency on the incoming POST request. Unfortunately we did not retain the :method, :request_path, and :query_string parameters from the conn so the signature validation and Oban Job would always fail.
This was most obvious when Mastodon sends Deletes for users your server has never seen before.
This is for a normal HTTP error response or timeout while receiving the data. A hard error from a process crash, DNS lookup failure, etc should produce a different response than {:ok, %Tesla.Env{}} and the request/job will be retryable.
