[bug] strip_report_status_data errors when trying to resolve/close a reopened closed report

shadowjonathan commented

2024-02-28 11:39:16 +00:00

Your setup

OTP

Extra details

Debian 12

Version

2024.11 stable / 3.11.0

PostgreSQL version

15

What were you trying to do?

Close or resolve a report.

The report was closed, but i wanted to move it to resolved reports. The report has no posts attached.

What did you expect to happen?

The issue to resolve or close normally.

What actually happened?

HTTP Error 500, and the issue cannot be closed or resolved.

Logs

Request: PATCH /api/v1/pleroma/admin/reports
** (exit) an exception was raised:
    ** (FunctionClauseError) no function clause matching in anonymous fn/1 in Pleroma.Web.ActivityPub.Utils.strip_report_status_data/1
        (pleroma 3.11.0-0-ga03f3a9) lib/pleroma/web/activity_pub/utils.ex:811: anonymous fn(nil) in Pleroma.Web.ActivityPub.Utils.strip_report_status_data/1
        (elixir 1.15.4) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2
        (pleroma 3.11.0-0-ga03f3a9) lib/pleroma/web/activity_pub/utils.ex:811: Pleroma.Web.ActivityPub.Utils.strip_report_status_data/1
        (pleroma 3.11.0-0-ga03f3a9) lib/pleroma/web/activity_pub/utils.ex:773: Pleroma.Web.ActivityPub.Utils.update_report_state/2
        (pleroma 3.11.0-0-ga03f3a9) lib/pleroma/web/admin_api/controllers/report_controller.ex:51: anonymous fn/2 in Pleroma.Web.AdminAPI.ReportController.update/2
        (elixir 1.15.4) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2
        (pleroma 3.11.0-0-ga03f3a9) lib/pleroma/web/admin_api/controllers/report_controller.ex:50: Pleroma.Web.AdminAPI.ReportController.update/2
        (pleroma 3.11.0-0-ga03f3a9) lib/pleroma/web/admin_api/controllers/report_controller.ex:5: Pleroma.Web.AdminAPI.ReportController.action/2

Severity

I cannot use the software

Have you searched for this issue?

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

### Your setup OTP ### Extra details Debian 12 ### Version 2024.11 stable / 3.11.0 ### PostgreSQL version 15 ### What were you trying to do? Close or resolve a report. The report was closed, but i wanted to move it to resolved reports. The report has no posts attached. ### What did you expect to happen? The issue to resolve or close normally. ### What actually happened? HTTP Error 500, and the issue cannot be closed or resolved. ### Logs ```shell Request: PATCH /api/v1/pleroma/admin/reports ** (exit) an exception was raised: ** (FunctionClauseError) no function clause matching in anonymous fn/1 in Pleroma.Web.ActivityPub.Utils.strip_report_status_data/1 (pleroma 3.11.0-0-ga03f3a9) lib/pleroma/web/activity_pub/utils.ex:811: anonymous fn(nil) in Pleroma.Web.ActivityPub.Utils.strip_report_status_data/1 (elixir 1.15.4) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2 (pleroma 3.11.0-0-ga03f3a9) lib/pleroma/web/activity_pub/utils.ex:811: Pleroma.Web.ActivityPub.Utils.strip_report_status_data/1 (pleroma 3.11.0-0-ga03f3a9) lib/pleroma/web/activity_pub/utils.ex:773: Pleroma.Web.ActivityPub.Utils.update_report_state/2 (pleroma 3.11.0-0-ga03f3a9) lib/pleroma/web/admin_api/controllers/report_controller.ex:51: anonymous fn/2 in Pleroma.Web.AdminAPI.ReportController.update/2 (elixir 1.15.4) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2 (pleroma 3.11.0-0-ga03f3a9) lib/pleroma/web/admin_api/controllers/report_controller.ex:50: Pleroma.Web.AdminAPI.ReportController.update/2 (pleroma 3.11.0-0-ga03f3a9) lib/pleroma/web/admin_api/controllers/report_controller.ex:5: Pleroma.Web.AdminAPI.ReportController.action/2 ``` ### Severity I cannot use the software ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

shadowjonathan added the

bug

label 2024-02-28 11:39:16 +00:00

shadowjonathan commented

2024-02-28 11:39:41 +00:00

Author

I see that #665 fixes this, but its been sitting for 3 months

Oneric commented

2024-02-28 19:21:23 +00:00

Member

hmmm, I’m not sure replacing other entries with nil (or keeping them nil) for later processing like #665 does is the best idea. Akkoma generates and seems to expect an empty list here for reports without activities and nils might now or in the future trip up something else.
Filtering them out might be better and with how stuff is currently arranged this is prob better done in transmofirifer.ex — though to deal with already existing entries we’ll need a mix task or duplicate the filtering here for a couple releases
(going further into bikeshed territory, i’m wondering whether to only filter out nils so we’ll notice if any other software start generating reports in a funny way, or filter out everything not matching our expectations so reports can at least be dealt with by admins even if they might have lost some info)

Do you know which server software generated those reports with a nil entry?

hmmm, I’m not sure replacing other entries with `nil` (or keeping them `nil`) for later processing like #665 does is the best idea. Akkoma generates and seems to expect an empty list here for reports without activities and `nil`s might now or in the future trip up something else. Filtering them out might be better and with how stuff is currently arranged this is prob better done in `transmofirifer.ex` — though to deal with already existing entries we’ll need a `mix` task or duplicate the filtering here for a couple releases *(going further into bikeshed territory, i’m wondering whether to only filter out `nil`s so we’ll notice if any other software start generating reports in a funny way, or filter out everything not matching our expectations so reports can at least be dealt with by admins even if they might have lost some info)* Do you know which server software generated those reports with a `nil` entry?

shadowjonathan commented

2024-02-28 21:13:23 +00:00

Author

The local server, it was done in a test to see if reports work with remote post references.

For some reason, the remote post didnt show up in the local or remote instance of the report, it may be a race condition, or bug when fetching posts (or something to that degree).

The local server, it was done in a test to see if reports work with remote post references. For some reason, the remote post didnt show up in the local or remote instance of the report, it may be a race condition, or bug when fetching posts (or something to that degree).

Oneric commented

2024-02-29 00:34:34 +00:00

Member

oh, good to know. If we generate those ourselves, doing anything in the transmogrifier is pointless and ideally we shouldn’t put nils in the list to begin with

At first glance, i can’t spot anything resulting in nils being inserted. Is this reproducible and if so can you describe how?

oh, good to know. If we generate those ourselves, doing anything in the transmogrifier is pointless and ideally we shouldn’t put `nil`s in the list to begin with At first glance, i can’t spot anything resulting in `nil`s being inserted. Is this reproducible and if so can you describe how?

shadowjonathan commented

2024-02-29 10:28:51 +00:00

Author

No idea, its possible that some action or the likes inserts a nil when trying to reference a post, wrt :error/:ok, i have near to no information here, but this was all generated locally :/

The newness of the instance might play a role, the instance was less than 24 hours old, and i was referencing some heavily-connected users/posts, i tried to report one of my own posts on a remote instance, which might've caused this.

Would it be possible the problem sits with receiving JSON from the api, that it sends null somewhere?

No idea, its possible that some action or the likes inserts a `nil` when trying to reference a post, wrt `:error`/`:ok`, i have near to no information here, but this was all generated locally :/ The newness of the instance might play a role, the instance was less than 24 hours old, and i was referencing some heavily-connected users/posts, i tried to report one of my own posts on a remote instance, which might've caused this. Would it be possible the problem sits with receiving JSON from the api, that it sends `null` somewhere?

Oneric commented

2024-03-01 03:35:55 +00:00

Member

Good(?) news, in testing locally i got this to reproduce and think i understand the problem(s) now:

After creation posts are already stripped (i was expecting/hoping it for some, but all of them disappeared). At this point the in-database form looked like:

"object": ["https://someremo.te/users/aaaaa", {"id": null, "deleted": true}, {"id": null, "deleted": true}]

This showed up as 0 reports in the admin dashboard and I was still able to change the state (deleted: true entries get filtered at some point iirc).

However, trying to change the state again failed and now the DB content assumed the below problematic form

"object": ["https://someremo.te/users/aaaaa", null, null]

There are two issues here:

We transform {id: "something", deleted: true} to just "something" when changing state in strip_report_status_data (the easy part)
The id is null/nil after creation

How come the id is nil? Well, in my case, since the local instance doesn’t federate (and can’t fetch from authfetch hosts), the posts in question were manually loaded by putting their URL into the search box. I’m guessing the same is true for you and presumably the post for the report from #665 was also manually fetched by some user.

If a post gets fetched this way we directly get the Note object without seeing the original Create activity. We still put a dummy Create activity down, but as it turns out those fabricated activities don’t have an ActivityPub id. Since the report builder wants to normalise everything to activity AP IDs it ends up reading back nil (and presumably then thinks they’ve must already been deleted) (in build_flag_object?).

In an ideal setup, perhaps we wouldn’t need to fabricate Create activities for notes, but unfortunately *oma like to refer to notes by the database ID of their Create activity in several public places like URLs and API. I guess we either need to (retroactively) create dummy AP IDs for fabricated activities, or allow the note object’s AP ID to remain and query both tables if the first doesn’t yield a match.

The first may potentially fix more yet-unknown similar issues but is more invasive and might break stuff on its own, the latter is simpler and unlikely to break something, but feels like a kludge.

Or maybe replace the internal representation of reported statuses everywhere with %{ap_uri: "https://...", api_id: <db id of create activity>} with ap_uri just being the received, unchanged URI for remote reports, and for local reports always put the note object uri to avoid the pitfall of fabricated Create activities. Will need a DB migration and possibly affect custom MRFs though; not sure what stability guarantees custom MRFs are promised

I’ll think about it a bit more and prob ask on IRC for opinions or better ideas, but yeah

Thanks for reporting and providing details for identifying the issue!

Good(?) news, in testing locally i got this to reproduce and _think_ i understand the problem(s) now: After creation posts are already stripped *(i was expecting/hoping it for some, but all of them disappeared)*. At this point the in-database form looked like: ``` "object": ["https://someremo.te/users/aaaaa", {"id": null, "deleted": true}, {"id": null, "deleted": true}] ``` This showed up as 0 reports in the admin dashboard and I was still able to change the state *(`deleted: true` entries get filtered at some point iirc)*. However, trying to change the state again failed and now the DB content assumed the below problematic form ``` "object": ["https://someremo.te/users/aaaaa", null, null] ``` --- There are two issues here: 1. We transform `{id: "something", deleted: true}` to just `"something"` when changing state in `strip_report_status_data` *(the easy part)* 2. The `id` is null/nil after creation How come the id is nil? Well, in my case, since the local instance doesn’t federate (and can’t fetch from authfetch hosts), the posts in question were manually loaded by putting their URL into the search box. I’m guessing the same is true for you and presumably the post for the report from #665 was also manually fetched by some user. If a post gets fetched this way we directly get the Note object without seeing the original Create activity. We still put a dummy Create activity down, but as it turns out those fabricated activities don’t have an ActivityPub `id`. Since the report builder wants to normalise everything to activity AP IDs it ends up reading back `nil` *(and presumably then thinks they’ve must already been deleted)* (in `build_flag_object`?). In an ideal setup, perhaps we wouldn’t need to fabricate Create activities for notes, but unfortunately \*oma like to refer to notes by the database ID of their Create activity in several public places like URLs and API. I guess we either need to (retroactively) create dummy AP IDs for fabricated activities, or allow the note object’s AP ID to remain and query both tables if the first doesn’t yield a match. The first may potentially fix more yet-unknown similar issues but is more invasive and might break stuff on its own, the latter is simpler and unlikely to break something, but feels like a kludge. Or maybe replace the internal representation of reported statuses everywhere with `%{ap_uri: "https://...", api_id: <db id of create activity>}` with `ap_uri` just being the received, unchanged URI for remote reports, and for local reports always put the note object uri to avoid the pitfall of fabricated Create activities. Will need a DB migration and possibly affect custom MRFs though; not sure what stability guarantees custom MRFs are promised I’ll think about it a bit more and prob ask on IRC for opinions or better ideas, but yeah Thanks for reporting and providing details for identifying the issue!

❤️ 1

shadowjonathan commented

2024-03-01 11:38:25 +00:00

Author

I’m guessing the same is true for you

Yes, the posts were fetched manually as they're pinned posts.

> I’m guessing the same is true for you Yes, the posts were fetched manually as they're pinned posts.

ilja commented

2024-03-02 18:37:49 +00:00

Contributor

If a post gets fetched this way we directly get the Note object without seeing the original Create activity. We still put a dummy Create activity down, but as it turns out those fabricated activities don’t have an ActivityPub id.

Objects indeed get wrapped in an activity, but when i check my server, the activities do have an id. This is also what I expect to happen. Am I misunderstanding something?

Here's how I look for such activities

select * from public.activities a 
where a.data ->> 'type' = 'Create'
and a.data ->> 'id' like 'https://ilja.space/%'
and a.data ->> 'object' not like 'https://ilja.space/%'
order by id desc

And here a random example, you can use the activity id in a browser nad it will open my instance and show the object, which is a remote post.

{
  "cc": [
    "https://vocalounge.cafe/users/samgai/followers",
    "https://raru.re/users/pasty"
  ],
  "id": "https://ilja.space/activities/f178d07c-1fe0-47e1-b064-93e4e8141c1c",
  "to": [
    "https://www.w3.org/ns/activitystreams#Public"
  ],
  "type": "Create",
  "actor": "https://vocalounge.cafe/users/samgai",
  "object": "https://vocalounge.cafe/users/samgai/statuses/107039805152066982",
  "context": "tag:raru.re,2021-10-03:objectId=8053581:objectType=Conversation",
  "published": "2021-10-03T21:50:14.687614Z",
  "context_id": 3657664
}

I remember reading about this behaviour in the spec, but it's only for client-to-server federation, https://www.w3.org/TR/activitypub/#object-without-create so I guess it's a pleroma-specific thing.

> If a post gets fetched this way we directly get the Note object without seeing the original Create activity. We still put a dummy Create activity down, but as it turns out those fabricated activities don’t have an ActivityPub id. Objects indeed get wrapped in an activity, but when i check my server, the activities do have an `id`. This is also what I expect to happen. Am I misunderstanding something? Here's how I look for such activities ```sql select * from public.activities a where a.data ->> 'type' = 'Create' and a.data ->> 'id' like 'https://ilja.space/%' and a.data ->> 'object' not like 'https://ilja.space/%' order by id desc ``` And here a random example, you can use the activity `id` in a browser nad it will open my instance and show the object, which is a remote post. ```json { "cc": [ "https://vocalounge.cafe/users/samgai/followers", "https://raru.re/users/pasty" ], "id": "https://ilja.space/activities/f178d07c-1fe0-47e1-b064-93e4e8141c1c", "to": [ "https://www.w3.org/ns/activitystreams#Public" ], "type": "Create", "actor": "https://vocalounge.cafe/users/samgai", "object": "https://vocalounge.cafe/users/samgai/statuses/107039805152066982", "context": "tag:raru.re,2021-10-03:objectId=8053581:objectType=Conversation", "published": "2021-10-03T21:50:14.687614Z", "context_id": 3657664 } ``` I remember reading about this behaviour in the spec, but it's only for client-to-server federation, https://www.w3.org/TR/activitypub/#object-without-create so I guess it's a pleroma-specific thing.

Oneric commented

2024-03-02 21:59:54 +00:00

Member

Objects indeed get wrapped in an activity, but when i check my server, the activities do have an id. This is also what I expect to happen. Am I misunderstanding something?

You’re probably understanding correctly, but we just get different results. On my local test server no activity for manually fetched posts has an ID (note you can’t fetch the ipv6.camp samples atm without changing config or applying #708):

akkoma=> \pset null '<null>'
akkoma=> SELECT id, data->>'id' AS ap_id, data->>'object' as object
         FROM activities
         WHERE data->>'type' = 'Create' AND data->>'object' NOT LIKE '%://localhost%';

                  id                  | ap_id  |                                object                                
--------------------------------------+--------+----------------------------------------------------------------------
 0000018d-f7b1-5b1b-b9ca-194f63b50000 | <null> | https://fedi.reimu.info/objects/b65f7231-90f9-4a0b-a523-159fbd8df467
 0000018d-f7b1-5824-b9ca-194f63b50000 | <null> | https://fedi.reimu.info/objects/80f0cf74-b9e8-4703-a8be-23b045753459
 0000018d-f7b1-59de-b9ca-194f63b50000 | <null> | https://fedi.reimu.info/objects/03085b00-c3cb-4074-a54b-f19aab879bc1
 0000018d-f7b1-56e8-b9ca-194f63b50000 | <null> | https://fedi.reimu.info/objects/b295d05e-3536-4e6d-acae-ffde0734e54a
 0000018d-e26f-54f6-e112-61f6611a0000 | <null> | https://ipv6.camp/users/alyx/statuses/111991922190522458
 0000018d-e267-8e9d-567c-cd43c3f60000 | <null> | https://ipv6.camp/users/alyx/statuses/111991914118934510
 0000018d-e267-8ca6-567c-cd43c3f60000 | <null> | https://ipv6.camp/users/alyx/statuses/111991911231838262
 0000018d-e25e-63a7-5d83-443c3a460000 | <null> | https://ipv6.camp/users/alyx/statuses/111991886167704059
 0000018d-e23e-9cec-0c1d-91156ef90000 | <null> | https://zug.network/users/f2k1de/statuses/111993587317319761
 0000018d-e23e-851d-0c1d-91156ef90000 | <null> | https://ipv6.camp/users/alyx/statuses/111991847856658408
 0000018d-e23e-82e4-0c1d-91156ef90000 | <null> | https://ipv6.camp/users/alyx/statuses/111991757204106028
 0000018d-86cf-3083-70df-0b8571a60000 | <null> | https://shonk.reimu.info/notes/9orl1eqdh7uv0018
(12 rows)

e.g.

{
  "cc": ["https://ipv6.camp/users/alyx/followers"],
  "to": ["https://www.w3.org/ns/activitystreams#Public"],
  "bcc": [],
  "bto": [],
  "type": "Create",
  "actor": "https://ipv6.camp/users/alyx",
  "object": "https://ipv6.camp/users/alyx/statuses/111991757204106028",
  "context": "tag:ipv6.camp,2024-02-25:objectId=4:objectType=Conversation"
}

I haven’t checked the code creating those "fake" activities. If it should get an ID then that’s the best fix (though as a side note, the internal report representation might benefit from a cleanup anyway; I’ve seen three different ways notes are represented).

Does your server still create IDs when you manually fetch something now and if not do you recall which version you were using the last time it worked?

> Objects indeed get wrapped in an activity, but when i check my server, the activities do have an id. This is also what I expect to happen. Am I misunderstanding something? You’re probably understanding correctly, but we just get different results. On my local test server *no* activity for manually fetched posts has an ID *(note you can’t fetch the `ipv6.camp` samples atm without changing config or applying #708)*: ```sql akkoma=> \pset null '<null>' akkoma=> SELECT id, data->>'id' AS ap_id, data->>'object' as object FROM activities WHERE data->>'type' = 'Create' AND data->>'object' NOT LIKE '%://localhost%'; id | ap_id | object --------------------------------------+--------+---------------------------------------------------------------------- 0000018d-f7b1-5b1b-b9ca-194f63b50000 | <null> | https://fedi.reimu.info/objects/b65f7231-90f9-4a0b-a523-159fbd8df467 0000018d-f7b1-5824-b9ca-194f63b50000 | <null> | https://fedi.reimu.info/objects/80f0cf74-b9e8-4703-a8be-23b045753459 0000018d-f7b1-59de-b9ca-194f63b50000 | <null> | https://fedi.reimu.info/objects/03085b00-c3cb-4074-a54b-f19aab879bc1 0000018d-f7b1-56e8-b9ca-194f63b50000 | <null> | https://fedi.reimu.info/objects/b295d05e-3536-4e6d-acae-ffde0734e54a 0000018d-e26f-54f6-e112-61f6611a0000 | <null> | https://ipv6.camp/users/alyx/statuses/111991922190522458 0000018d-e267-8e9d-567c-cd43c3f60000 | <null> | https://ipv6.camp/users/alyx/statuses/111991914118934510 0000018d-e267-8ca6-567c-cd43c3f60000 | <null> | https://ipv6.camp/users/alyx/statuses/111991911231838262 0000018d-e25e-63a7-5d83-443c3a460000 | <null> | https://ipv6.camp/users/alyx/statuses/111991886167704059 0000018d-e23e-9cec-0c1d-91156ef90000 | <null> | https://zug.network/users/f2k1de/statuses/111993587317319761 0000018d-e23e-851d-0c1d-91156ef90000 | <null> | https://ipv6.camp/users/alyx/statuses/111991847856658408 0000018d-e23e-82e4-0c1d-91156ef90000 | <null> | https://ipv6.camp/users/alyx/statuses/111991757204106028 0000018d-86cf-3083-70df-0b8571a60000 | <null> | https://shonk.reimu.info/notes/9orl1eqdh7uv0018 (12 rows) ``` e.g. ```json { "cc": ["https://ipv6.camp/users/alyx/followers"], "to": ["https://www.w3.org/ns/activitystreams#Public"], "bcc": [], "bto": [], "type": "Create", "actor": "https://ipv6.camp/users/alyx", "object": "https://ipv6.camp/users/alyx/statuses/111991757204106028", "context": "tag:ipv6.camp,2024-02-25:objectId=4:objectType=Conversation" } ``` I haven’t checked the code creating those "fake" activities. If it should get an ID then that’s the best fix *(though as a side note, the internal report representation might benefit from a cleanup anyway; I’ve seen three different ways notes are represented)*. Does your server still create IDs when you manually fetch something now and if not do you recall which version you were using the last time it worked?

ilja commented

2024-03-03 05:59:01 +00:00

Contributor

oh, you're correct o.o I should've noticed that yesterday. Indeed the last activity I find where the id was filled in is from 2021-10-03 21:50:14.000.

I also find those with id NULL[1], most recent one is today (2024-03-03 05:52:30.000)[2].

The oldest one with id NULL is 2020-08-31 05:35:21.000, but starting 2021-10-04 07:33:22.000 I'm seeing multiple per day. So it seems something in 2020-08 made it sometimes not be filled in, and then in 2021-10 the id was never filled in any more :/ Both are from before Akkoma.

The last Pleroma release before having the id always be NULL was 2.4.1, released 2021-08-21[3]. But I have no idea when I did the update and if I used stable or develop at the time. So I'm unsure if that release introduced it or was still OK.

[1]

select * from public.activities a 
where a.data ->> 'type' = 'Create'
and a.data ->> 'id' is null 
and a.data ->> 'object' not like 'https://ilja.space/%'
order by id desc

[2]

Backend version
    3.10.4

Frontend version
    e7a558a

[3] https://git.pleroma.social/pleroma/pleroma/-/tree/v2.4.1?ref_type=tags

oh, you're correct o.o I should've noticed that yesterday. Indeed the last activity I find where the `id` was filled in is from 2021-10-03 21:50:14.000. I also find those with `id` `NULL`[1], most recent one is today (2024-03-03 05:52:30.000)[2]. The oldest one with `id` `NULL` is 2020-08-31 05:35:21.000, but starting 2021-10-04 07:33:22.000 I'm seeing multiple per day. So it seems something in 2020-08 made it sometimes not be filled in, and then in 2021-10 the `id` was never filled in any more :/ Both are from before Akkoma. The last Pleroma release before having the `id` always be `NULL` was 2.4.1, released 2021-08-21[3]. But I have no idea when I did the update and if I used stable or develop at the time. So I'm unsure if that release introduced it or was still OK. [1] ```sql select * from public.activities a where a.data ->> 'type' = 'Create' and a.data ->> 'id' is null and a.data ->> 'object' not like 'https://ilja.space/%' order by id desc ``` [2] Backend version 3.10.4 Frontend version e7a558a [3] https://git.pleroma.social/pleroma/pleroma/-/tree/v2.4.1?ref_type=tags

Oneric commented

2024-03-04 13:49:34 +00:00

Member

Both are from before Akkoma.

fwiw, after checking Pleroma merges, they encountered the same issue and initially just ignored nils as a quick fix.
Then pleroma#3788 switched things up to prefer object ids. Unfortunately (as so often) there’s no explanation or discussion around the approach itself, so idk if they knew why activities have nil ids aand chose to keep this, or if this was just a workaround for mysterious nils.

Sidenote: more recently Pleroma also fixed an issue with handling reports of an already deactivated users in pleroma#3915, we might want to check if this also applies to us.

> Both are from before Akkoma. fwiw, after checking Pleroma merges, they encountered the same issue and initially just ignored `nil`s as a quick fix. Then [pleroma#3788](https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3788) switched things up to prefer object ids. Unfortunately (as so often) there’s no explanation or discussion around the approach itself, so idk if they knew why activities have `nil` ids aand chose to keep this, or if this was just a workaround for mysterious `nil`s. Sidenote: more recently Pleroma also fixed an issue with handling reports of an already deactivated users in [pleroma#3915](https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3915), we might want to check if this also applies to us.

[bug] strip_report_status_data errors when trying to resolve/close a reopened closed report #712

Your setup

Extra details

Version

PostgreSQL version

What were you trying to do?

What did you expect to happen?

What actually happened?

Logs

Severity

Have you searched for this issue?