Conversation

Notices

1. cassidyclown (cassidyclown@clubcyberia.co)'s status on Tuesday, 05-Sep-2023 19:39:32 JST cassidyclown
   maybe it'll never happen again (delusional)
   •  (mint@ryona.agency)'s status on Tuesday, 05-Sep-2023 19:39:31 JST 

     in reply to
     @cassidyclown Here's an idea: take a backup of your current database, then drop all objects and activities made before you pruned it. Restore the unpruned database separately and backup only the activities and objects tables, then restore them onto the current database. Don't know if this is exactly what you did already or not, but it might work depending on how many cross-table references there are. You might also need to regenerate indexes (REINDEX DATABASE pleromer), though that will take a lot of time.
   • cassidyclown (cassidyclown@clubcyberia.co)'s status on Tuesday, 05-Sep-2023 19:45:02 JST cassidyclown

     in reply to

     • 
     @mint I only did objects and not activities. I did a database reindex and it didn't affect it. I'm going to try putting back activities too now since there's nothing else to try but I'm worried that would double the amount of errors if it just messes with activities in the same way. The full error is:
     
     [error] Task #PID<0.13844.0> started from #PID<0.13774.0> terminating
     ** (Ecto.ConstraintError) constraint error when attempting to insert struct:
     
     * "objects_pkey" (unique_constraint)
     
     If you would like to stop this constraint violation from raising an
     exception and instead add it as an error to your changeset, please
     call `unique_constraint/3` on your changeset with the constraint
     `:name` as an option.
     
     The changeset defined the following constraints:
     
     * "objects_unique_apid_index" (unique_constraint)
     
     (ecto 3.10.2) lib/ecto/repo/schema.ex:804: anonymous fn/4 in Ecto.Repo.Schema.constraints_to_errors/3
     (elixir 1.14.0) lib/enum.ex:1658: Enum."-map/2-lists^map/1-0-"/2
     (ecto 3.10.2) lib/ecto/repo/schema.ex:788: Ecto.Repo.Schema.constraints_to_errors/3
     (ecto 3.10.2) lib/ecto/repo/schema.ex:769: Ecto.Repo.Schema.apply/4
     (ecto 3.10.2) lib/ecto/repo/schema.ex:377: anonymous fn/15 in Ecto.Repo.Schema.do_insert/4
     (pleroma 2.5.54-321-g17c336de-develop) lib/pleroma/web/activity_pub/activity_pub.ex:102: Pleroma.Web.ActivityPub.ActivityPub.persist/2
     (pleroma 2.5.54-321-g17c336de-develop) lib/pleroma/web/activity_pub/pipeline.ex:49: Pleroma.Web.ActivityPub.Pipeline.do_common_pipeline/2
     (ecto_sql 3.10.1) lib/ecto/adapters/sql.ex:1203: anonymous fn/3 in Ecto.Adapters.SQL.checkout_or_transaction/4
     Function: #Function<7.11561101/0 in Pleroma.Web.ActivityPub.ActivityPub.make_user_from_ap_id/2&gt;
     Args: []
      likes this.
   • JAJAX (jajax@clubcyberia.co)'s status on Tuesday, 05-Sep-2023 19:46:09 JST JAJAX

     in reply to

     • 
     @mint @cassidyclown that uh... seems like it may fuck shit up even worse
   •  (mint@ryona.agency)'s status on Tuesday, 05-Sep-2023 19:46:09 JST 

     in reply to

     • JAJAX
     @JAJAX @cassidyclown I don't know, it might result in less rows being out of order. An alternative variant would be to backup activities/objects of both the cleared current and unpruned database, truncate a/o of the current DB, restore a/o from the unpruned, then restore a/o from the current on top.
   •  (mint@ryona.agency)'s status on Tuesday, 05-Sep-2023 19:51:38 JST 

     in reply to
     @cassidyclown Looking at trace, I guess it's trying to federate some remote user to the instance, but can't since an object for said user (but not the user itself in users table) already exists.
   • cassidyclown (cassidyclown@clubcyberia.co)'s status on Tuesday, 05-Sep-2023 19:53:29 JST cassidyclown

     in reply to

     • 
     @mint why would that randomly fuck with people trying to make a post though
   •  (mint@ryona.agency)'s status on Tuesday, 05-Sep-2023 19:53:29 JST 

     in reply to
     @cassidyclown No idea. That was just my hypothesis since I never dug up into the DB that much. As long as it works, I don't touch it.
   • cassidyclown (cassidyclown@clubcyberia.co)'s status on Wednesday, 06-Sep-2023 00:28:37 JST cassidyclown

     in reply to

     • Kirino Kousaka
     @Kirino the primary key is the id and it only increments by one each time there's a new object which as far as I can tell is determined by objects_id_seq sequence. The current value for the sequence is a bit higher than the max id in the objects table. If it was lower than the max id I think it would trigger a unique violation error every single time it attempts to insert an object. But this error only occurs sometimes - like once ever half-hour to an hour or sometimes longer going by logs. That's the really weird part.
      likes this.
   • cassidyclown (cassidyclown@clubcyberia.co)'s status on Wednesday, 06-Sep-2023 00:28:37 JST cassidyclown

     in reply to

     • Kirino Kousaka
     @Kirino holy shit the sequence was lower than the max object id yet somehow it didn't trigger an error every single time - my eyes literally added a zero when I said it was higher which wouldn't make any sense anyway since it's supposed to be the same value
      likes this.
   • Kirino Kousaka (kirino@seal.cafe)'s status on Wednesday, 06-Sep-2023 00:28:38 JST Kirino Kousaka

     in reply to

     Am I wrong in thinking the whole issue is the DB is trying to insert over your primary key and raising an error?

     If so, am I missing why you couldn’t just set the next primary key to be greater than the maximum object on the table? :\