Issues with remote follows [SOLVED] (solved more by accident than design)


#1

So I’ve recently set up an instance and I’ve run into a strange behaviour that I assume is down to a subtle misconfiguration at my end.

When I attempt to remote follow a user, for example Mastodon (@Mastodon@mastodon.social) - Mastodon I click through the choosing which account to follow from, and end up on the /authorize_interaction page on my own instance which reports:

“Unfortunately, there was an error looking up the remote account”

If I go and find the @mastodon@mastodon.space profile at my end (via Moderation -> Accounts) and look at it, it shows with the hourglass as “Awaiting approval. Click to cancel follow request”.

If I cancel the follow request (and click Unfollow) that seems to work - I can then click the “Follow” button and it seems to work this time - however when I then look at my profile the account doesn’t show up in my follows, and if I reload the profile it again shows the hour glass.

Configuration wise I pretty much followed Installation - Mastodon documentation

For debugging I have checked the nginx logs and see a whole bunch of 200 OK requests.

Checking journalctl for mastodon-web shows:

method=POST path=/api/v1/accounts/4/follow format=html controller=Api::V1::AccountsController action=follow status=200 duration=64.98 view=0.93 db=9.62

Checking journalctl for mastodon-sidekiq shows a bunch of ActivityPub::DeliveryWorker things which have starts and ends and nothing else so probably fine.

Checking journalctl for mastodon-streaming means every time I refresh the local view of the profile page I see (account 2 is mine)

npm[804]: verb 23ae7fe5-692d-4361-9632-d9db794d4ec8 Ending stream for 2
npm[804]: verb Unsubscribe timeline:2
npm[804]: verb e17ea342-6042-4eb9-94b8-446921f1dd2f Starting stream from timeline:2 for 2
npm[804]: verb Subscribe timeline:2

The server is using:
Mastodon 2.6.1
Ruby 2.5.3p105
PostgreSQL 10.6
Redis 4.0.9
Ubuntu 18.04


#2

Can you link your instance?

Are there any failed jobs in /sidekiq?


#3

This and the “stuck follow request” both indicate that for some reason your instance is unreachable from other servers. Perhaps your ipv6 or https is misconfigured?


#4

This is my understanding of the problem from reading other threads, my ipv6 was initially misconfigured but I’ve since taken that out of DNS and stopped nginx listening on IPv6

I’ve got 36 Failed jobs in sidekiq apparently, although reading journalctl -u mastodon-sidekiq | grep ERROR doesn’t find any since this morning when I broke Redis for a bit.

The plot thickens however. I apologised about this to one of the other users on the instance who reported things worked fine. I’ve just made a brand new test account and that seems to work just fine.

Broken account is here: https://loci.onl/.well-known/webfinger?resource=acct:morix@loci.onl
Working test account is here: https://loci.onl/.well-known/webfinger?resource=acct:testaccount_2018_11_18@loci.onl

So the question now is how have I knackered this one account? And should I just chalk it up to strangeness and attempt to delete and recreate it?


#5

If you try to use the broken account to follow an account on a completely different domain, like https://glitch.social, does that work?


#6

Tried to do a follow on bea@glitch.social and that attempt has displayed the behaviour of allegedly working, but not adding the account to my follow list, and again if I visit the web account I see the egg timer.

A while back I managed to follow an account from botsin.space, but that is now displaying the same behaviour (egg timer on pabloinspiration@botsin.space / https://loci.onl/web/accounts/32 and no follow)


#7

Okay so came back to this after a break, totally tore down the account. Removed with tootctl, then a little touch up SQL to fully purge it, then recreated it with tootctl.

I now seem to be able to follow accounts from instances I’ve not been in touch with before and that seems to be working.

So I have a theory that something on the remote instances was caching my details as an account that was impossible to communicate with - probably from when I had badly routed IPv6 (possibly some other fault) and until that caching expires things just won’t work and remote follows won’t complete.

I don’t actually know the internals of Mastodon well enough to guess at where this caching could be, so I’ll give it 24-48 hours and update this ticket with the results of if its working or not.

Other suggestions welcome in the meantime.


#8

That was my guess as well, but unless you happened to have changed your domain name or someone broke your private keys, i’m also somewhat confused about what kind of state your account could have been in.

Your new account has a different name then the old one, correct?


#9

Well if you’re super interested I could probably have a poke around in backups, I snapshotted the DB before doing horrible things to it.

But yes I’m really not sure how or what could have been broken.

Nope, accounts with new names were just working fine, like every other account on the instance seems to work, and the new one works with instances I’ve not touched before, hence why I figure the name is being cached somewhere on a list as broken/frozen-for-retries or whatever and hopefully it’ll start to work in a day or two.

Otherwise I guess I’ll hop names.

Ta for your help, I’ll check back in 24-48 hours and report if things have magically started to work.


#10

Oh, sorry, I misread your last post as saying that the new account was working completely. Yes, I would imagine that it would be very confusing to remote mastodon instances when your stuff changes.

I would check again in 48 hours and see if the issue persists.


#11

I return, and can confirm that whatever the issue was totally nuking the account, that waiting 48-72 hours seems to have pretty much fixed it as far as I can tell.

It’s highly possible that just waiting time would also have fixed it :slight_smile:

Thanks for your help in investigative ideas @nightpool