Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stuck Follow Request when following a WordPress Profile #27458

Closed
pfefferle opened this issue Oct 18, 2023 · 21 comments · Fixed by #27586
Closed

Stuck Follow Request when following a WordPress Profile #27458

pfefferle opened this issue Oct 18, 2023 · 21 comments · Fixed by #27586
Labels
bug Something isn't working status/to triage This issue needs to be triaged

Comments

@pfefferle
Copy link

Steps to reproduce the problem

  1. Go to for example mastodon.art
  2. Search for pfefferle@notiz.blog
  3. Press "Follow" button

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

@pfefferle pfefferle added bug Something isn't working status/to triage This issue needs to be triaged labels Oct 18, 2023
@ClearlyClaire
Copy link
Contributor

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.

@pfefferle
Copy link
Author

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.

@pfefferle
Copy link
Author

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.

@mro
Copy link

mro commented Oct 19, 2023

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.

@ClearlyClaire
Copy link
Contributor

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.

image

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?

@HashRaygoza
Copy link

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.

Captura desde 2023-10-22 14-53-33

Captura desde 2023-10-22 14-54-18

Captura desde 2023-10-22 14-54-44

@ShadowJonathan
Copy link
Contributor

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.

@ShadowJonathan
Copy link
Contributor

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.

@pfefferle
Copy link
Author

pfefferle commented Oct 24, 2023

@ShadowJonathan Have you enabled AUTHORIZED_FETCH on you server?

@ShadowJonathan
Copy link
Contributor

ShadowJonathan commented Oct 24, 2023

@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.

@pfefferle
Copy link
Author

pfefferle commented Oct 24, 2023

@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?

@ShadowJonathan
Copy link
Contributor

I had to clear delivery errors first, but then it went through.

@pfefferle
Copy link
Author

pfefferle commented Oct 24, 2023

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?

@ShadowJonathan
Copy link
Contributor

ShadowJonathan commented Oct 24, 2023

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
    }
}

@pfefferle
Copy link
Author

OK, that's the AUTHORIZED_FETCH issue, will have a look at that. Thanks!

@hugogameiro
Copy link
Contributor

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 #27458 (comment)

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 #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.

@ShadowJonathan
Copy link
Contributor

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).

@ShadowJonathan
Copy link
Contributor

The auth-fetch issue is better able to be tracked in Automattic/wordpress-activitypub#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

@pfefferle
Copy link
Author

thanks a lot @ShadowJonathan 🎉

@IanWelsh920
Copy link

Just a brief comment to note that I'm getting this same issue.

https://mstdn.social/@ianwelsh.net@www.ianwelsh.net

@pfefferle
Copy link
Author

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working status/to triage This issue needs to be triaged
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants