It is not useful to call maybe_federate() with the processed
activity, because it will only record the activity id, and put
it into the queue. When the job is invoked, it reads from the database
for the activity. This means the changes we just made will be
discarded.
In this commit, I moved the stripping and anonymizing procedures
to Transmogrifier.prepare_outgoing, which is called after the
federator reads the activity from the database.
For protected branches, it seems now just CI_JOB_TOKEN is not enough.
https://gitlab.com/gitlab-org/gitlab-foss/-/issues/36898#note_38415655
According to this, the CI_JOB_TOKEN is based on whoever created the
job and creating a pipeline on a protected branch requires special
permissions. Somehow this still did not work for other people who
merged, even though they had access to the docs repo.
Also return 404 when the user who sent the activity is believed to be
deactivated. It was already an error, now it just returns a better
reason than "Invalid request". Also send proper errors when either
user is not known at all.
This clarifies what is really going on here and removes confusion about the nested Enum.each |> Enum.each which both were using an assignment called "inboxes"
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.
This was used in OTP releases where the normal OTP_VERSION file
is unavailable.
If checking against OTP minor versions and patch levels
is needed again, revert this commit and commit mentioned below.
Context: 1be8deda73
warning: Credo.CLI.Command.Info.Output.Default.print_after_info/4 is undefined or private. Did you mean:
* print/2
│
4 │ use Credo.CLI.Output.FormatDelegator,
│ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
│
└─ lib/credo/cli/command/info/info_output.ex:4: Credo.CLI.Command.Info.InfoOutput.print_after_info/4
This does not seem to be the intended behaviour, as the code that produces it
did not actually ever do anything and just returned the tag as-is.
See
lib/pleroma/web/activity_pub/object_validators/tag_validator.ex
and
https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4358#note_112681
At least Mastodon and Misskey output tags without the # from their API,
so in reality tags with the hash should rarely happen.
