Closed pfefferle closed 10 months ago
I am unable to reproduce the issue from mastodon.social, mastodon.online, or my own private server.
Sending an accept by hand, on the other hand, seems to work.
Another way to reset the follow process seems to be an @-reply. After sending an @-reply to the Mastodon profile,an unfollow/re-follow also seems to work.
This makes me think the server might have been ruled as unavailable by Mastodon. This happens if delivery attempts fail for 7 different days with no success in-between and no delivery from the supposedly-undeliverable server to our own.
But shouldn't a valid follow request (all endpoints return the correct informations during this process) reset that state then? Is it possible to debug that state in the Admin backend?
What speaks against that is, that the WordPress.com release is less than 7 days old and we already had users with that issue.
A lot of these issues seem to happen on instances hosted by masto.host, is there a setting/configuration/setup that might cause this issue?
This phenomenon seem to be relatively new, because the plugin worked nicely together with some of the instances for quite some time.
ruled as unavailable by Mastodon
Hi @ClearlyClaire,
how can 'unavailable' be reset?
Sorry for hijacking, but seems on topic. Author of https://seppo.social here. I may be an 'unavailable' victim at https://digitalcourage.social and am in contact with the admin https://digitalcourage.social/@chpietsch/111260615834845738.
But shouldn't a valid follow request (all endpoints return the correct informations during this process) reset that state then?
It would not, the request would not be issued.
Is it possible to debug that state in the Admin backend?
On the mastodon side, yes, in the moderation interface, the “Federation” section will show if a server is considered available for delivery, with some information and options to restart delivery or outright delete any data about the server.
cc @mro this should also answer your question
What speaks against that is, that the WordPress.com release is less than 7 days old and we already had users with that issue.
Yes, that does seem to contradict this theory…
A lot of these issues seem to happen on instances hosted by masto.host, is there a setting/configuration/setup that might cause this issue?
Not that I know of, but maybe we could investigate with masto.host. Do you know of specific servers exhibiting the issue?
I have the exact same issue with a blog hosted in wordpress.com, I enabled the fediverse plugin, try to follow from both mastodon.art and me.dm and in both I get a 500 error, it seems to follow but then goes to awaiting.
The Delivery Tracker seems to be fixated on public-api.wordpress.com
, while the domain is almost always not that same domain, so the "clear delivery errors" button will not do anything.
That domain is then also not visible in the federation tab, so it cannot be clicked "clear delivery errors", i had to go into the rails console to figure out that public-api.wordpress.com
is stuck on 7 days non-delivery, probably during a collective outage, ive only just now been able to clear it.
After clearing the delivery error, and refreshing the remote URL, it seems to constantly fail on a Mastodon::UnexpectedResponseError
, HTTP code 401, to a follow request, and the likes.
@ShadowJonathan Have you enabled AUTHORIZED_FETCH on you server?
@pfefferle yes, and for the record, i expect that to become more prevalent, especially since mastodon has added an accessible checkmark to enable it in the admin console.
@ShadowJonathan yes totally! It has to work on WordPress.com and I am working on a fix! This might be also an issue of the different API host.
Can you verify that it might be an WordPress.com issue and try to follow my other non WordPress.com blog @pfefferle@notiz.blog
to see if it works like expected?
I had to clear delivery errors first, but then it went through.
notiz.blog went through? So this is also only a WordPress.com issue! Thanks!
Can you see the errors? Why is the plugin producing so much errors?
This is one such error;
Oct 24 07:39:58 queue-workers bundle[2238100]: 2023-10-24T07:39:58.391Z pid=2238100 tid=2h47g WARN: {
"context": "Job raised exception",
"job": {
"retry": 16,
"queue": "push",
"dead": false,
"args": [
"{\"@context\":\"https://www.w3.org/ns/activitystreams\",\"id\":\"https://tech.lgbt/2934a834-34af-4242-a06a-136b3ae12b3c\",\"type\":\"Follow\",\"actor\":\"https://tech.lgbt/users/ShadowJonathan\",\"object\":\"http://kyefox.com/@kyefox.com\"}",
105209,
"https://public-api.wordpress.com/wpcom/activitypub-1.0/sites/157570986/users/0/inbox"
],
"class": "ActivityPub::DeliveryWorker",
"jid": "de314061f74dce8ce21febaa",
"created_at": 1698133153.8004045,
"enqueued_at": 1698133196.5979354,
"error_message": "https://public-api.wordpress.com/wpcom/activitypub-1.0/sites/157570986/users/0/inbox returned code 401",
"error_class": "Mastodon::UnexpectedResponseError",
"failed_at": 1698133154.6045635,
"retry_count": 1,
"retried_at": 1698133175.397954
}
}
OK, that's the AUTHORIZED_FETCH issue, will have a look at that. Thanks!
I believe there are 3 issues being reported here.
1 - instances with AUTHORIZED_FETCH enabled are not compatible with the WordPress ActivityPub plugin - confirmed by @pfefferle at https://github.com/mastodon/mastodon/issues/27458#issuecomment-1776760108
2 - Problem with featured tags implementation in the Wordpress ActivityPub plugin - probably a different issue should be opened regarding this.
3 - There is no way to revert a domain 'Failure threshold' (7 days) if the domain in question does not "federate" with the instance where the 'Failure threshold' was reached.
This last point is probably closer to the OP and I don't even think it's because Wordpress.com uses a different domain public-api.wordpress.com
for ActivityPub.
I think that what is happening on some instances is that the public-api.wordpress.com
has reached the 'Failure threshold' (I see that domain listed on the unavailable_domains
table in the database on an instance that it's still failing to federate with Wordpress.com blogs).
That is not displayed in Mastodon administration web interface because https://github.com/mastodon/mastodon/issues/27525. But even on a situation where the domain showed up in the Mastodon administration web interface as having reached the 'Failure threshold' that would make no difference because there is no option for the admin to clear the 'Failure threshold' or to force a retry.
AFAIK, the only thing that will remote the 'Failure threshold' from a domain, is if that domain federates/communicates with the instance where the 'Failure threshold' has been triggered.
This can be problematic in a situation where a local user searches for a remote profile (that no other local user follows) and the profile federates like normal but when they try to follow that account, the follow fails due to some problem with the remote server (in this case public-api.wordpress.com
was failing for some time). Then, if the remote server continues to try for 7 days and it keeps failing it is marked as an "unavailable_domain".
As Mastodon will only remove the domain from unavailable_domains
if the remote server federates with the instance, and the only reason for the remote server to federate is if it knows that someone on that server follows the account making the post, then it gets stuck endlessly because the follow never federated and cannot federate until the domain is manually removed from the unavailable_domains
or the remote server "forces" a federation to that server.
I've created #27586, which is intended to help with one half of this problem; the fact that federation is wedged because of this issue, and isn't easily able to be unwedged.
The other half of this problem is for @pfefferle to fix on wordpress' side, where AF can be properly processed.
After this, and after an update, wordpress.com-hosted blogs can be properly accessed once more (after users cancel and refollow blogs they tried to follow).
The auth-fetch issue is better able to be tracked in https://github.com/Automattic/wordpress-activitypub/issues/523, the mastodon side of this issue (where it is about being able to send follow requests in the first place when delivery is wedged) has been fixed by #27586
thanks a lot @ShadowJonathan 🎉
Just a brief comment to note that I'm getting this same issue.
@IanWelsh920 this seems to be a different issue! Your WebFinger endpoint does not work properly. It should return JSON but seems to load your frontpage https://www.ianwelsh.net/.well-known/webfinger?resource=acct%3Aianwelsh.net%40www.ianwelsh.net
Steps to reproduce the problem
pfefferle@notiz.blog
Expected behaviour
Mastodon user follows WordPress User
Actual behaviour
Process seem to be stuck ("Cancel follow")
Detailed description
We have received some reports (here is the ticket on the WordPress plugin repo) that the Follow process seems to be stuck and not accepted by the WordPress instance.
Debugging on the WordPress site shows that when searching for the WordPress profile, all required endpoints (WebFinger, Followers, ...) are requested and the profile is displayed correctly in the Mastodon UI. However, after clicking the follow button, WordPress does not receive a follow request (or any other requests to the inbox), this also applies to a unfollow/re-follow. Sending an
accept
by hand, on the other hand, seems to work.Another way to reset the follow process seems to be an @-reply. After sending an @-reply to the Mastodon profile,an unfollow/re-follow also seems to work.
An example profile: @pfefferle@notiz.blog An example group: @notiz.blog@notiz.blog
For a few weeks now, the Mastodon UI has also been displaying a 500 error in the UI when requesting the internal featured-tags endpoint: https://mastodon.social/api/v1/accounts/[...]/featured_tags.
Here is an example endpoint for the Featured Tags endpoint of WordPress: https://notiz.blog/wp-api/activitypub/1.0/users/0/collections/tags
Mastodon instance
mastodon.art, mastodon.ie, twit.social
Mastodon version
v4.2.1
Technical details
No response