Hi arpinux,
Thanks for the report the root cause has been identified and fixed.
Root cause two bugs in RssService
1. Unstable <guid> / Atom <id> (main culprit)
The unique identifier for each feed item was built from the full discussion
URL,
including the slug derived from the title:
/d/123-my-discussion-title
When a discussion title is edited, the slug changes — and so does the
identifier.
Feed readers like Thunderbird use this identifier to track which items have
already
been read or deleted. When it changes, the reader treats the item as a
brand-new
entry and shows it again, indefinitely.
Fixed by using only the stable, slug-free URL as identifier:
/d/123
The number never changes regardless of title edits, so the identifier stays
permanent across the lifetime of the discussion.
2. <lastBuildDate> always set to the current time
The RSS channel's lastBuildDate was set to date('r') — the wall-clock time
at the moment the feed was fetched. This meant the feed always appeared
freshly
updated on every single request, even when no content had changed. Some
readers
use this field to decide whether to re-evaluate feed items.
Fixed by computing the actual date of the most recent discussion in the
feed,
matching the existing behaviour of the Atom <updated> element.
Bonus fix: the Atom <updated> per-entry now uses updated_at when
available
(i.e. when a discussion has been edited), falling back to created_at.
Previously
it always reported the creation date even for edited discussions.
The fix is in app/Services/RssService.php.
Upgrading should resolve the repeated reappearance ofold items in Thunderbird immediately no action needed on your end beyond the update.
Can you try with this file (rename to php).
