AkkomaGang/akkoma

Fork 115

DM timeline omits most received DMs #798

New issue

Closed

opened 2024-06-10 17:00:28 +00:00 by Oneric · 1 comment

Oneric commented

2024-06-10 17:00:28 +00:00

Owner

Your setup

From source

Extra details

Fedora 40

Version

develop (d1c4b97613) + #796

PostgreSQL version

don’t know

What’s wrong?

The DM timeline (akkoma-fe: users/<your_nick>/dms; backend: /api/v1/timelines/direct?with_muted=false) shows all sent DMs, but only rarely, with no discernable pattern, includes received DMs.

It’s supposed to contain both and for messages created before 2024-03-01 this seems to be the case. At least as of 2024-03-11 most received DMs are missing though. The instance frequently updates to latests develop although not always immediately. Something appears to have changed in how direct messages are stored just before the security patches of 2024.03 got merged.

Some received DMs which show up in the backend response, do not appear in the fronted; there might be an additional fe bug, but many DMs are already missing in the backend response.

Note: Mastodon deprecated this timeline in favour of a new conversations API. We do actually implement this already, but aparently the frontend doesn’t use them yet. Still, it prob shouldn’t omit half the messages.

Looking at those “conversations” received DMs appear correclty as the last_status where expected. Afaict there’s no way to directly query a whole conversation, i’m guessing the intended usage is to just fetch the last status and all its parents which should work normally (don’t know if/how conversations are split if different subthreads emerge).

jq filters to make backend reponses easier to read:

# DM timeline
curl -H 'Authorization: ...' 'https://example.org/api/v1/timelines/direct?limit=20' | jq '[.[] | {"id": .id, "author": .account.acct, "source": .akkoma.source}]'

# Conversations API
curl -H 'Authorization: ...' https://example.org/api/v1/conversations | jq '[.[] | {"id": .id, "accounts": [.accounts[] | .acct], "last_status": {"author": .last_status.account.acct, "source": .last_status.akkoma.source }}]'

Logs

No response

Severity

I can manage

Have you searched for this issue?

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

### Your setup From source ### Extra details Fedora 40 ### Version develop (d1c4b97613e72891ea1f9c109a3e9c0f3052bdaf) + #796 ### PostgreSQL version don’t know ### What’s wrong? The DM timeline (akkoma-fe: `users/<your_nick>/dms`; backend: `/api/v1/timelines/direct?with_muted=false`) shows all _sent_ DMs, but only rarely, with no discernable pattern, includes _received_ DMs. It’s supposed to contain both and for messages created before 2024-03-01 this seems to be the case. At least as of 2024-03-11 most _received_ DMs are missing though. The instance frequently updates to latests develop although not always immediately. Something appears to have changed in how direct messages are stored just _before_ the security patches of 2024.03 got merged. Some received DMs which show up in the backend response, do not appear in the fronted; there might be an additional fe bug, but many DMs are already missing in the backend response. Note: Mastodon [deprecated this timeline](https://docs.joinmastodon.org/methods/timelines/#direct) in favour of a new conversations API. We do actually implement this already, but aparently the frontend doesn’t use them yet. Still, it prob shouldn’t omit half the messages. Looking at those “conversations” received DMs appear correclty as the `last_status` where expected. Afaict there’s no way to directly query a whole conversation, i’m guessing the intended usage is to just fetch the last status and all its parents which should work normally (don’t know if/how conversations are split if different subthreads emerge). `jq` filters to make backend reponses easier to read: ```sh # DM timeline curl -H 'Authorization: ...' 'https://example.org/api/v1/timelines/direct?limit=20' | jq '[.[] | {"id": .id, "author": .account.acct, "source": .akkoma.source}]' # Conversations API curl -H 'Authorization: ...' https://example.org/api/v1/conversations | jq '[.[] | {"id": .id, "accounts": [.accounts[] | .acct], "last_status": {"author": .last_status.account.acct, "source": .last_status.akkoma.source }}]' ``` ### Logs _No response_ ### Severity I can manage ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

Oneric added the

bug

label

2024-06-10 17:00:28 +00:00

Oneric referenced this issue from a commit

2025-12-20 02:06:33 +00:00

Remove DM timeline

Oneric referenced this issue from a commit

2025-12-21 03:39:04 +00:00

Remove DM timeline

Oneric referenced this issue from a commit

2025-12-22 18:13:25 +00:00

Remove DM timeline

Oneric referenced this issue from a commit

2026-04-06 18:12:27 +00:00

api: drop direct timeline

Oneric commented

2026-04-06 18:40:27 +00:00

Author

Owner

It’s supposed to contain both and for messages created before 2024-03-01 this seems to be the case. At least as of 2024-03-11 most received DMs are missing though.

It may not have been a change in Akkoma’s code, but something to do with the instance. On a different much smaller and younger instance both kinds of posts continued to show up much later, while it kept being bugged for the instance i originally reported this for.
Even more, on the original instance results became unstable. That is, requering the endpoint with the same parameters may sometimes drop or add a few posts (all of which should always appear in the TL). Not sure when that started though and no firm idea of why it happened.

Either way, this timeline is bout to be removed for good so this won’t be relevant anymore.

> It’s supposed to contain both and for messages created before 2024-03-01 this seems to be the case. At least as of 2024-03-11 most received DMs are missing though. It may not have been a change in Akkoma’s code, but something to do with the instance. On a different much smaller and younger instance both kinds of posts continued to show up much later, while it kept being bugged for the instance i originally reported this for. Even more, on the original instance results became _unstable_. That is, requering the endpoint with the same parameters may sometimes drop or add a few posts (all of which should _always_ appear in the TL). Not sure when that started though and no firm idea of why it happened. Either way, this timeline is bout to be removed for good so this won’t be relevant anymore.

Oneric referenced this issue from a commit

2026-04-06 20:54:44 +00:00

api: drop direct timeline

Oneric referenced this issue from a commit

2026-04-07 13:18:11 +00:00

api: drop direct timeline

Oneric referenced this issue from a commit

2026-04-07 14:04:53 +00:00

api: drop direct timeline

Oneric closed this issue

2026-04-14 18:36:06 +00:00