Issue Summary

Older deleted pages do not appear in space trash when trash contains more than 500 items due to pagination based on content creation date, making some deleted items effectively undiscoverable and unrestorable via UI.

---

Environment

• Product: Confluence Cloud

• Area: Space Trash / Delete & Restore content

---

Description

We recently introduced pagination for space trash to avoid timeouts when a space has a very large number of deleted items.

However, the current implementation:

• Sorts trashed items by original content creation date, not by "moved to trash" date.

• Limits the UI to only the first ~500 results, with no apparent pagination to access older items.

In large spaces with many deleted items, this causes older deleted pages (or page trees) to:

• Still exist in a deleted/in trash state in the backend / DB.

• Be visible as delete events in the audit log.

• Not appear anywhere in the space trash UI, so space admins cannot self‑serve to restore or purge them.

For affected customers, this looks like the page was deleted and then "vanished" without any purge event, when in reality it's just not reachable in the paginated trash UI.

 

---

Steps to Reproduce

• Use / simulate a Confluence Cloud space with:
  • A large amount of deleted content (space trash) - >500 items.
• In that space:
  • Identify an old page (early creation date) and delete it.
• Go to:
  • Space settings → Content → Trash for that space.
• Attempt to locate the deleted page in the trash list.

---

Actual Result

• The page:
  • Has status = deleted in the database.
  • Triggers a "content deleted" entry in the audit log.
• There is no audit log entry for purge or permanent deletion.

• The page does not appear in the space trash UI at all:
  • It is not in the visible list of trash items.
  • There is no way to reach it via pagination (no "next page" or similar).
• From the customer's perspective, the page seems:
  • Deleted,
  • Not in trash,
  • Not purged,
  • And non‑recoverable via UI.

Expected Result

• Any content item with status = deleted for a given space should:
  • Be discoverable in the space trash UI, regardless of:
    • Original creation date,
    • Space size or volume of deleted items.
• Space admins should be able to:
  • See, restore, or purge the item from the trash.
• Pagination should:
  • Respect "deleted/moved‑to‑trash date" ordering (not original creation date), or
  • At minimum, provide functional pagination controls (next/previous pages) so that all trashed items can be accessed.

---

Impact

• Functional impact for customers
  • Space admins cannot self‑serve to:
    • Restore older deleted pages,
    • Confirm whether items are still in trash or already purged.
• Appears as data loss or "ghost deletion" (no purge logs, no item visible).
  • Affects large spaces (commonly enterprise customers) that:
    • Have 500+ deleted items,
    • Regularly clean up / refactor content.
• Operational impact on Support / Product
  • Requires engineering intervention:
    • Identifying the item in DB,
    • Toggling feature gates per tenant as a workaround.
  • Leads to escalations and confusion around data deletion behavior.

---

Workaround

For affected tenants: (For the Support Engineers)

1. Use Switcheroo to exclude the tenant from the view_trash_action_paginated gate: