[Bug Report] Inability to Create Deleted Community with Lack of Warning and Unresponsive Button

[ghost]

When a community is deleted if someone searches for it, it doesn't appear on the communities and if he then tries to create it the button keeps spinning without any warning that the community already exists. The only people who can restore the community are the admin and the person who deleted it in the first place. I think there should be a warning indicating that the community already exists and the button shouldn't spin. Or the moderators could be kicked out and the person trying to create the community made the new moderator. I don't see any reason for moderators to sit on a removed community.

[charwrangler404]

I also discovered this bug, can confirm it occurs on UI: v0.17.3. Perhaps this can be solved by dropping the right data from the database?

[Nutomic]

Can you check in the browser console if there is an error logged?

[ghost]

I haven't seen any error in the console.

[dessalines]

We'll have to leave this until after our http rework. It could be a SQL issue, not doing a check first, and so not returning a proper LemmyError to the front end.

[charwrangler404]

This I think is the relevent log. It's noted that when this happens, it locks up postgres and it won't make new entries into the database, effectively sending registration to a black hole of spinny death.

postgres_1  | 2023-06-08 17:53:40.925 UTC [28] ERROR:  duplicate key value violates unique constraint "idx_activity_ap_id"
postgres_1  | 2023-06-08 17:53:40.925 UTC [28] DETAIL:  Key (ap_id)=(https://prime8s.xyz/activities/create/772bff2b-fe0f-4499-9c06-3cf04b4577da) already exists.
postgres_1  | 2023-06-08 17:53:40.925 UTC [28] STATEMENT:  INSERT INTO "activity" ("data", "local", "updated", "ap_id", "sensitive") VALUES ($1, $2, DEFAULT, $3, $4) RETURNING "activity"."id", "activity"."data", "activity"."local", "activity"."published", "activity"."updated", "activity"."ap_id", "activity"."sensitive"
postgres_1  | 2023-06-08 17:57:46.434 UTC [21] LOG:  checkpoint starting: time
postgres_1  | 2023-06-08 17:58:05.833 UTC [21] LOG:  checkpoint complete: wrote 194 buffers (1.2%); 0 WAL file(s) added, 0 removed, 0 recycled; write=19.370 s, sync=0.011 s, total=19.400 s; sync files=74, longest=0.003 s, average=0.001 s; distance=751 kB, estimate=751 kB

I haven't tried posting while it's in this state, but I'd suspect you'd get similar behavior. I can try it if you think it'll give you more information, I have relatively few users and can take a hit for a few minutes.