[bug] Replies whose parent can’t be fetched aren’t treated as replies in REST API #715

New Issue

Open

opened 2024-03-01 03:58:49 +00:00 by Oneric · 1 comment

Oneric commented

2024-03-01 03:58:49 +00:00

Member

Your setup

From source

Extra details

Alpine 3.19

Version

3.11 (issue exists for longer)

PostgreSQL version

What were you trying to do?

When Akkoma receives a reply notice but can’t load the parent post, all relevant in_reply_* fields in the REST API will be null making frontends and apps think this is a top-level post. However, at least for the samples I have here, in the database it is still referencing the AP ID of the parent post, so Akkoma knows this is a reply.

This can happen e.g. due to MRF rejecting the parent, temporary remote downtime or the thread being follower-only and nobody on the local instance follows the parent poster making remote refuse our request.

I guess since it can’t fetch the parent, it’s unable to find a matching activity in the DB and thus can’t fill out the fields with valid ID.

What did you expect to happen?

Replies remain identifyable as replies; e.g. by pointing in_reply_to_id, in_reply_to_account_id and pleroma.in_reply_to_account_acct to a placeholder post and user nobody has perms to fetch.

What actually happened?

Frontend treats them as top-level posts

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 Alpine 3.19 ### Version 3.11 (issue exists for longer) ### PostgreSQL version 16 ### What were you trying to do? When Akkoma receives a reply notice but can’t load the parent post, all relevant `in_reply_*` fields in the REST API will be `null` making frontends and apps think this is a top-level post. However, at least for the samples I have here, in the database it is still referencing the AP ID of the parent post, so Akkoma _knows_ this is a reply. This can happen e.g. due to MRF rejecting the parent, temporary remote downtime or the thread being follower-only and nobody on the local instance follows the parent poster making remote refuse our request. I guess since it can’t fetch the parent, it’s unable to find a matching activity in the DB and thus can’t fill out the fields with valid ID. ### What did you expect to happen? Replies remain identifyable as replies; e.g. by pointing `in_reply_to_id`, `in_reply_to_account_id` and `pleroma.in_reply_to_account_acct` to a placeholder post and user nobody has perms to fetch. ### What actually happened? Frontend treats them as top-level posts ### 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-03-01 03:58:49 +00:00

Oneric commented

2024-03-09 15:42:02 +00:00

Author

Member

We concluded on IRC that e.g. # or _ would be a good placeholder IDs to use for unavailable users and posts, since afaiu:

it’s not a valid base62 sequence
it’s not a decimal number
since it is also shorter than 18 characters, Flake(CompatType) decoding will return nil instead of raising an exception
for #: it will terminate URLs so trying to resolve it will never lead to an actual lookup on the server (undecided if good or bad)

We concluded on IRC that e.g. `#` or `_` would be a good placeholder IDs to use for unavailable users and posts, since afaiu: - it’s not a valid base62 sequence - it’s not a decimal number - since it is also shorter than 18 characters, `Flake`(`CompatType`) decoding will return `nil` instead of raising an exception - for `#`: it will terminate URLs so trying to resolve it will never lead to an actual lookup on the server *(undecided if good or bad)*

No Milestone

No project

No Assignees

1 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#715

No description provided.