A follow request sent again carries a new id

Lemmy keeps the ids of the activities it received and never answers one again, so resending the same Follow could not
heal a follow whose Accept it lost: the village's community follow stayed pending through two resends. Each resend is
now the same follow under its own id (<follow id>-again-<n>), and an Accept naming any of them answers the follow;
the Undo still embeds the follow, so servers match it by its actor and object. Sent this way, the stuck follow was
accepted at once.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LsXgEaXee4GCU1hwYgPJXw
This commit is contained in:
thepraandClaude Opus 5.5 committed 2026-10-05 10:45:18 +02:00
1 parent a5d493a8c9
commit 206506f5e9
5 files changed
+28 -7

No files matched your search

+3
View File
@@ -533,6 +533,9 @@ What it showed:
- **Every bare `Announce{object}` is answered 400** (`Failed to parse object`: Lemmy dereferences it expecting an
activity), as Lemmy answers the compatibility `Announce(Page)` it sends itself. Both 400s show up as dead deliveries
in the statistics.
- **It keeps the ids of the activities it received and never answers one again.** A follow it took and whose Accept it
lost (sent before its worker for our server started) stayed pending through two resends of the same Follow; sent
under a new id (2026-10-05), it was accepted at once (the village's community follow, pending since 05:06).
- **Votes travel only to the community**, which relays them as `Announce{Like}` and `Announce{Dislike}`: counted since
ed08f80, and a vote turned the other way replaces the first since bbeeda7. A moderator's removal, lock and ban come
the same way and are applied since 2026-10-05 (the removal was applied all along; the scenario gave up before Lemmy's