An uncommon but somewhat difficult to digagnose issue is dealing with
improperly-seeded databases. In such cases, instance-signed fetches will
fail with a ActiveRecord::RecordNotFound error, usually caught and handled
as generic 404, leading people to think the remote resource itself has not
been found, while it's the local instance actor that does not exist.
This commit changes the code so that failure to find the instance actor
automatically creates a new one, so that improperly-seeded databases do
not cause any issue.
* Improve Emoji import
Skip macOS '._' shadow files in tar archive to speed up import
* Fix codeclimate format issue with whitespace
* Update lib/mastodon/emoji_cli.rb
suggestions from Gargron to improve comment
Co-authored-by: Eugen Rochko <eugen@zeonfederated.com>
* Update emoji_cli.rb
Remove extraneous comment (macOS-specific comment now with correct line)
Co-authored-by: Eugen Rochko <eugen@zeonfederated.com>
* Fix maintenance script not re-indexing some indexes on textual values
Fixes#15475
* Refresh instance view at the end of the maintenance script run
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
* Fix media processing getting stuck on too much stdin/stderr
See thoughtbot/terrapin#5
* Remove dependency on paperclip-av-transcoder gem
* Remove dependency on streamio-ffmpeg gem
* Disable stdin on ffmpeg process
Database serialization failure occurs when a read-replica is used
and a query takes long enough that rows on the primary database
become unavailable. It should return HTTP 503 as it is temporary.
Re-order rescue definitions according to their status codes
* Fix crash on receiving requests with missing Digest header
Return an error pointing out that Digest is missing, instead of crashing.
Fixes#15743
* Fix from review feedback
* Fix URI of repeat follow requests not being recorded
In case we receive a “repeat” or “duplicate” follow request, we automatically
fast-forward the accept with the latest received Activity `id`, but we don't
record it.
In general, a “repeat” or “duplicate” follow request may happen if for some
reason (e.g. inconsistent handling of Block or Undo Accept activities, an
instance being brought back up from the dead, etc.) the local instance thought
the remote actor were following them while the remote actor thought otherwise.
In those cases, the remote instance does not know about the older Follow
activity `id`, so keeping that record serves no purpose, but knowing the most
recent one is useful if the remote implementation at some point refers to it
by `id` without inlining it.
* Add tests
This also skips fetching the actor completely.
This will be useful if we end up distributing Update activities linked to
account suspensions more widely (they are currently only delivered to
the suspended account's followers), as currently, instances not knowing
about the suspended account would fetch it to then process the suspension.
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
Unlike locally-issued blocks, they weren't clearing follow
relationships in both directions, follow requests or notifications.
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
* Add tests
* Ensure deleted statuses are marked as such
* Save some redis memory by not storing URIs in delete_upon_arrival values
* Avoid possible race condition when processing incoming Deletes
* Avoid potential duplicate Delete forwards
* Lower lock durations to reduce issues in case of hard crash of the Rails process
* Check for `lock.aquired?` and improve comment
* Refactor RedisLock usage in app/lib/activitypub
* Fix using incorrect or non-existent sender for relaying Deletes
* Fix being able to import more than allowed number of follows
Without this commit, if someone tries importing a second list of accounts to
follow before the first one has been processed, this will queue imports for
the two whole lists, even if they exceed the account's allowed number of
outgoing follows.
This commit changes it so the individual queued imports aren't exempt from
the follow limit check (they remain exempt from the rate-limiting check
though).
* Catch validation errors to not re-queue failed follows
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
Fixes#15374
When the pop-out player was introduced, it had tweaks for the mobile
view, but it's now disabled in mobile mode and the styling was reused
for modals, causing the footer to be hidden on mobile without a good
reason.
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
As a regression from the recent optimizations, mentions were left untouched
until `account.destroy`, which would then delete them individually,
and executing queries to find and delete associated notifications, resulting
in a massive slowdown.
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
