AkkomaGang/akkoma

Fork 91

[bug] loss of posts from Akkoma #822

New issue

Open

opened 2024-07-23 21:53:09 +00:00 by mirabilos · 2 comments

mirabilos commented

2024-07-23 21:53:09 +00:00

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:

ME = me on GtS 0.16.0rc3
SO = sender on Akkoma 3.13.2
TP = third party on Mastodon 4.2.10

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:

today, SO sent a DM to ME and TP
I got it, went to reply in Semaphore and saw only @SO in the textarea and added @TP manually
TP asked what post I was referring to, as he did not receive the thread starter from SO

At 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, the mentions 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 the mentions 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 across statuses for multiple <a class="u-url mention" but lower array size of mentions, 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 and outbox, unlike Mastodon, GtS and Pleroma), and I was able to look at a public Note from Akkoma… which had:

[…]
  "tag": [
    {
      "href": "https://stereophonic.space/users/newt",
      "name": "@newt@stereophonic.space",
      "type": "Mention"
    },
    {
      "href": "https://suya.place/users/a1ba",
      "name": "@a1ba@suya.place",
      "type": "Mention"
    }
  ],
[…]

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

I have no way to obtain any logs on the Akkoma side of this, as these are operated by others.

Severity

I cannot use it as easily as I'd like

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### 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: - ME = me on GtS 0.16.0rc3 - SO = sender on Akkoma 3.13.2 - TP = third party on Mastodon 4.2.10 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: - today, SO sent a DM to ME and TP - I got it, went to reply in Semaphore and saw only `@SO` in the textarea and added `@TP` manually - TP asked what post I was referring to, as he did not receive the thread starter from SO At 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, the `mentions` 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 the `mentions` 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 across `statuses` for multiple `<a class="u-url mention"` but lower array size of `mentions`, 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` and `outbox`, unlike Mastodon, GtS and Pleroma), and I was able to look at a public Note from Akkoma… which had: ``` […] "tag": [ { "href": "https://stereophonic.space/users/newt", "name": "@newt@stereophonic.space", "type": "Mention" }, { "href": "https://suya.place/users/a1ba", "name": "@a1ba@suya.place", "type": "Mention" } ], […] ``` 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 ```shell I have no way to obtain any logs on the Akkoma side of this, as these are operated by others. ``` ### Severity I cannot use it as easily as I'd like ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

mirabilos added the

bug

label 2024-07-23 21:53:09 +00:00

mirabilos commented

2024-07-23 21:56:07 +00:00

Author

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.

Oneric commented

2024-07-31 20:22:01 +00:00

Member

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.

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:

So, two mentions. However, in the GtS database, there was only one mention!

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.

> 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. 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: > So, two mentions. However, in the GtS database, there was only one mention! 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.

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#822

No description provided.