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).
Hi @arpinux,
Fixed
- RSS/Atom feed resurfaces old discussions when they receive new replies — The feed was sorted by
updated_at, so any reply bumped old discussions to the top of the feed. Atom's<updated>field also usedupdated_at, causing Thunderbird and other Atom readers to treat the entry as freshly updated and mark it unread again. The feed is now sorted bycreated_atso old discussions never bubble up, and Atom<updated>usescreated_atso entry timestamps are immutable.
Files changed:app/Services/RssService.php.
Can you try with this file (rename to php).
Sorry it came back, @arpinux.
I had a better look at what's actually happening.
The v5.6.3 fix re-sorted discussions by created_at inside the feed service but the storage layer was still fetching by updated_at and cutting the list to 20 items before returning it.
So the moment someone replies to an old thread,
its updated_at bumps it into the top-20 activity window.
The created_atre-sort that came after was just shuffling cards that were already wrong.
The real fix in v5.6.5: the feed now fetches without any limit from storage.
Filtering, date sorting, and pagination all happen in PHP after that, on the
full pool. Old discussions can't sneak in just because someone posted in them.
For the global /rss and /atom feeds specifically, it uses
getAllDiscussionsSorted('newest'), which sorts by created_at DESC at the SQL level (SQLite) or in the PHP sort (JSON storage) before any slicing.
Let me know if you still see stale items after updating. The feed cache is 15
minutes, so give it a moment before testing.
Can you try with this file (rename to php).
Edited on May 24, 2026 By Fred .
