This is the header described in the ActivityPub spec, which should fix
some federation problems with GoToSocial and potentially other picky
services.
Related: #2794, superseriousbusiness/gotosocial#1676
Previously, ignore_activity could unexpectedly make a outgoing HTTP
connection, leading to unwanted latency, particularly when called via
ActivityObject.to_model, which had the allow_external_connections
parameter already.
Related: #2717
Since we don't use the results of our Celery tasks (all of them return
None implicitly), it's prudent to set the ignore_result flag, for a
potential performance improvement. See the Celery docs for details [1].
We could do this with the global CELERY_IGNORE_RESULT setting, but it
offers more flexibility if we want to use task results in the future to
set it on a per-task basis.
[1]: https://docs.celeryq.dev/en/stable/userguide/tasks.html#ignore-results-you-don-t-want
When an inbox activity comes in from another fediverse instance, the
behavior prior to this commit was always to immediately give a 200
response to the external server and then create a celery activity
(usually in the MEDIUM_PRIORITY queue) to complete it.
Instead, this would receive a request and try to complete it without
making any http requests (which would make the request take too long to
process). If an external request is required to complete the activity, a
task is created and added to the queue.
Ideally, this will cause some tasks to happen very promptly, and reduce
the load on celery, which would help queued tasks happen more quickly as
well.
One downside is that this will make completing http requests from
external servers slowing (since it's doing a bunch of thinking before
responding).
- when using raise_for_status we need to catch an HTTPError, not a ConnectionError
- simplify instance actor - use internal email address since it will never be used anyway, and make default username less likely to already be in use.
ERROR HANDLING FIXES
- use raise_for_status() to pass through response code
- handle exceptions where no response object is passed through
INSTANCE ACTOR
- models.User.objects.create_user function cannot take an ID
- allow instance admins to determine username and email for instance actor in settings.py
Properties like "tag" could be lists containing multiple subclasses of
ActivityObject. Make sure to serialize them recursively instead of
outputting them as they are, because otherwise we could get a bunch of
nulls in the resulting JSON and that wouldn't necessarily be a valid
JSON-LD object.
Fix: #2451
These errors in resolve_remote_id aren't really errors, they're
routine problems that we can expect from dealing with the outside world,
like a connection timeout, a server being down, a server being blocked,
et cetera. It's cluttering up the logs and causing unnecessary worry.
When mastodon is in authorized fetch mode any request has to be signed
or it fails with 401. This adds the needed signature to the requests
made to discover the actor when receiving something from mastodon (such
as a follow request)
