[bug] loss of posts from Akkoma #822
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#822
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Your setup
No response
Extra details
No response
Version
3.13.2
PostgreSQL version
No response
What were you trying to do?
We have a setup with multiple communication partners who occasionally send each other direct messages:
What I first noticed was that occasionally, SO said she had sent me DMs (to just ME or to both ME and TP) which I haven’t received. I thought this a federation issue in GotoSocial, as it was in its early stages, and opened https://github.com/superseriousbusiness/gotosocial/issues/2496 there, but it was eventually closed because we had no way to look deeper at it.
What now follows is a summary of the last post in the issue, so feel free to skip it if you read it there:
@SO
in the textarea and added@TP
manuallyAt this point I begun debugging. Looking into the GtS DB showed me that while there are two
<a class="u-url mention" …>
links in the content, thementions
column has an array with just one account ID (namely mine).(At this point, SO (on Akkoma) tried to edit the post, adding another
@TP
mention, but while the textual change showed up, neither did it show up in thementions
array nor did TP become able to see it.)I did a couple database queries more. I looked in
instances
which instances all used the exact same Akkoma version (6 in total), then did a query acrossstatuses
for multiple<a class="u-url mention"
but lower array size ofmentions
, but unlisted or public posts (so I could actually look at the AP with a shell script I have that can do signed GET requests).A bit of fiddling later (turns out Akkoma requires the actor to have an
inbox
andoutbox
, unlike Mastodon, GtS and Pleroma), and I was able to look at a public Note from Akkoma… which had:So, two mentions. However, in the GtS database, there was only one mention! (The thing I can obviously not look at is the POST to my inbox which probably populated the GtS DB.)
Unfortunately, the operator of the Akkoma instance I found the public post on is not knowledgeable enough to debug it, and I’m not sure if the admin of SO’s instance is (they run multiple instances of multiple different instance softwares, so they’re probably too busy) plus debugging something with private messages is iffy.
I’ve no idea if there’s something we can do on the GtS side to debug this. If you could figure out if there’s something on the Akkoma side, a fix for this would be very welcome.
What did you expect to happen?
Posts that mention someone trigger a notification for that someone and are visible to that someone.
What actually happened?
Posts sometimes get lost (trigger no notification (even if I have notifications for the sender in general enabled)) and sometimes are even not visible to a mentioned communication partner (private messages).
Logs
Severity
I cannot use it as easily as I'd like
Have you searched for this issue?
To clarify, both Akkoma → GotoSocial and Akkoma → Mastodon loses messages and access, which is why I thought here would be the next logical good place to try and debug this.
If none of the involved Akkoma instance operators can/wants to debug, i’m afraid it will be near impossible to get any insight onto what happpens at Akkoma’s end.
Still, some notes:
If it has two mentions in the federated AP response, but GtS only parsed one, this suggests something goes wrong after GtS received the post. In theory it’s also possible the post originally had only one mention and was later edited ig, but you can test this by deleting your locally cached version and then refetching the post from its id. If it still only shows one mention, start debugging GtS’ processing
Otherwise at least for the
* → Akkoma
direction, direct messages may end up intentionally dropped if the intended receiver set up their account to e.g. reject DMs from non-followers. Idk if Mastodon and GtS have similar settings. Similar if any of the involved servers blocks another server or user.Apologies for bumping this... 8 month old thread, but I've honestly been suffering from this bug for months now on a public Akkoma node I run, and I somehow missed that this bug report was opened or I'd have thrown my hat into the ring when it was still fresh.
I'm not exactly a god when it comes to Elixir (I know just enough to be dangerous), but I'm totally down to give you whatever data I can if there's anything I can do to help triage this. Worth noting is that I don't see any bugs or errors on my end when this occurs - the only sign of trouble is that I hear a while later that the affected folks I'm replying to just never saw any notice of my response. I have no idea where in the pipeline it happens or why it happens, but if there's anything on my end I can do to resolve it, I'd like to do that.
Just to clarify again, the "mentions differ" issue from OP almost certainly isn’t an Akkoma bug but an issue on the receiver side.
For the other issue of posts not arriving, it may be on either or even both sides, which means at least one and possibly both sides need to assist in debugging. First of all you should ensure there are no server- or user-side blocks/defeds or mutes and that DMs are accepted from all authors (at least Akkoma allows each user to restrict who can send you DMs; other DMs will be dropped). Without any involved admin actually looking into it, there’s nothing we can do.
As a first check on your (Akkoma) side:
SELECT id, host, unreachable_since, updated_at FROM instances WHERE host = ANY('{example.org,domain2.example}');
If thi is the case, usually it should be marked as reachable again automatically if any activity from the domain is received.
Should neither apply, the issue is most likely on the receiving end.
Checking the instances marked as unreachable, none of them are ones I actively know this issue is occurring with.
As of this moment, I don't have Prometheus metrics scraping set up yet. I'll look into getting that set up.
On the latest release you might also be able to use the Oban dashboard (got o
/akkoma/oban
while logged in as an admin account). However, the dashboard might not keep data around for as long as victoriametrics/prometheus do, so you might need to be quick. On the upside it revelas more information about the failed jobs.If you spot a failed publisher job in the Oban dashboard, please also check the job details to confirm it’s related to your DM and why it failed.
I attempted sending a message to someone I know has been experiencing the related issue, and I'm not seeing any errors pop up in the dashboard. I tried drilling down to see if I could find more details about what succeeded towards federating to their node (maybe if some value was off?), but the events disappear from that dashboard after only 90 seconds, so I wasn't able to find the specific task where it federated to their instance in time. (All the more reason for me to set up more long-term monitoring...)
you may be able to extend the time it remains with:
happened today again: SO sent a DM to TP and me, putting the @ for TP first because apparently TP isn’t getting the DM (so it’s not a GtS problem), and I don’t get the post
well, what’s in your logs? did you receive the document into your personal inbox, but failed processing, did you never get a inbox POST at all, something else?
As I wrote before just "doesn't work" is in no way actionable and involved admins actually need to debug this to provide specific info.
I was hoping to provide a data point so that an Akkoma developer can possibly reproduce it, as I found the “second mention in a DM doesn’t get the post” quite systematic.
There is no admin involved on the Akkoma side, and the DMs in question have a level of privacy in which we’d rather keep it that way.
Looking at my (GtS side) logs, even the Apache httpd in front did not get any connection from the Akkoma instance in the timeframe in question.
SO also just told me something which I interpret as “TP replied to the post but TP’s client’s automatic mentioning on replies also replied to just SO, not me”, so the guess is that Akkoma somehow doesn’t format multiple mentions right in messages it sends out, in a way affecting both GtS and Mastdarm instances.
Ok, this bit is helpful and suggests either your account or your instance domain is (partially) blocked either by the post author or the author’s instance admin OR your instance is considered "unreachable" by the sending instance (keep in mind not all blocks are published).
Without actually involving the instance admin though, there’s no way to say anything further or if really neither of the above applies detect what else might go wrong. Thus if you don't want to do this, there’s nothing to do here and you’ll just have to hope whatever BlueRacoon experiences and actually debugs will end up helping you too.
Pretty implausible, we communicate over this all the time.
I just asked SO to send a DM to just me, and it arrived, both in the timeline and in notifications.
Incidentally, SO then sent a test DM to TP and me in that order again, and it did arrive this time.
It also worked when adding a picture, as in the lost post.
I have another extra debugging thing, in case it helps.
SO navigated to the post in question (which did not federate to me) in the stock webfrontend with F12→Network open and sent me the HAR, and I extracted the JSON object in question and (hopefully) anonymised it sufficiently to post but still show all included detail (I mostly just inserted lots of Xes and 999s instead of IDs and used
{so,tp,my}_name@{so,tp,my}-domain.example
for handles via search/replace).