[Feature] Implement automated pool archival and cleanup for completed/inactive pools with data preservation

[Sendi0011]

Getting Started

1. Fork the repository: https://github.com/JointSave-org/Joint_Save
2. Clone your fork:

git clone https://github.com/<your-username>/Joint_Save.git
cd Joint_Save

3. Create a new branch:

git checkout -b feat/pool-archival-cleanup

---

Overview

As JointSave grows, completed and inactive pools accumulate in the Explore page and My Groups tab, cluttering the UI and degrading performance. Currently, there is no mechanism to archive completed pools, remove inactive pools from discovery, or clean up stale data. The pools table in Supabase has a status column but no automated transitions occur.

Checked frontend/app/explore/page.tsx — fetches all pools via /api/pools without filtering by status. The My Groups tab shows all pools the user is a member of regardless of completion status. Pool contracts remain deployed on-chain indefinitely.

This issue adds an automated archival system that identifies completed/inactive pools, moves them to an archived state, hides them from discovery views (while preserving historical data), and provides an archival dashboard for reviewing past pools.

Requirements

Database Changes

• Add to pools table:
  • archived_at (timestamptz, nullable)
  • archive_reason (text, nullable): completed, inactive_90d, admin_archived, emergency_withdrawn
• Migration: ALTER TABLE pools ADD COLUMN archived_at timestamptz, ADD COLUMN archive_reason text

Automated Archival Logic

• New Vercel Cron endpoint: POST /api/cron/archive-pools
  • Runs daily at 02:00 UTC
  • Criteria for archival:
    1. Completed pools: status = 'completed' and completed_at is older than 7 days (grace period for viewing)
    2. Inactive pools: no activity in pool_activity for 90 days AND all members have empty deposits (never deposited or fully withdrawn)
    3. Emergency withdrawn: status = 'emergency_withdrawn' and emergency_withdrawn_at is older than 30 days
  • Sets archived_at and archive_reason for matching pools
  • Sends a summary notification to each affected pool's admin
  • Logs archival actions in a new archive_log table

Frontend Changes

• Modify Explore page:

  • Exclude archived pools from the default query
  • Add a "Show Archived" toggle (off by default)
  • Archived pools show a grayed-out card with "Archived" badge

• Modify My Groups page:

  • Separate tabs: "Active" and "Archived"
  • Archived tab shows completed/inactive pools in a compact list view
  • Each archived pool shows: name, type, completion date, final TVL, reason for archival

• New component: frontend/components/shared/archived-pool-card.tsx

  • Compact card for archived pools
  • Shows pool name, type, archived date, reason
  • "View History" button that opens a read-only view of the pool detail page

• Modify pool detail page for archived pools:

  • All data is read-only (no deposit/withdraw/pause buttons)
  • "Archived" banner at the top explaining the archival reason
  • Activity feed still accessible but marked as historical
  • "This pool has been archived and is no longer active" message

API Changes

• GET /api/pools — add archived query param (default: false) to include/exclude archived pools
• PUT /api/pools/[id]/archive — manual admin archival (body: reason)
• PUT /api/pools/[id]/unarchive — reverse archival (admin only)

Data Preservation

• Archived pools retain all Supabase data (pool metadata, members, activity)
• On-chain contract data is immutable and unaffected
• Archived pools can still be viewed in read-only mode
• Historical data export remains available for archived pools

Acceptance Criteria

• Cron job correctly identifies completed, inactive, and emergency-withdrawn pools
• Archived pools are hidden from Explore and My Groups by default
• Archived pools can be viewed with a toggle/tab
• Archived pool detail pages are fully read-only
• Admins can manually archive and unarchive pools
• Archival actions are logged in the archive_log table
• Archived pools retain all historical data and activity
• "Show Archived" toggle works correctly on Explore page
• Archived tab on My Groups shows compact list of past pools
• No performance degradation on Explore/My Groups pages after archival

[Promise278]

i have experience with sytem design and archecture i would love to work on these please

[Cyberking99]

Hello maintainer, for this issue, I would implement an automated pool lifecycle system that identifies completed or inactive pools based on configurable criteria, preserves all required historical and audit data, and safely archives or removes data that is no longer needed for active operation if assigned to me.

[Dopezapha]

Hi maintainer, I would love to resolve this issue by getting the archival criteria and read-only enforcement exactly right first, since a false-positive archival (a still-active pool getting hidden) would be a real trust problem for users. I will:

1. Write the migration adding archived_at (timestamptz, nullable) and archive_reason (text, nullable) to the pools table, and create the new archive_log table to record every archival action (which pool, which reason, timestamp, and whether it was automated or admin-triggered).
2. Build POST /api/cron/archive-pools implementing the three criteria precisely: completed pools where completed_at is older than 7 days (respecting the grace period so users can still review a just-completed pool), inactive pools with no pool_activity for 90 days where every member's deposits are empty (never deposited or fully withdrawn, not just currently zero-balance mid-cycle), and emergency-withdrawn pools where emergency_withdrawn_at is older than 30 days.
3. Confirm the inactive-pool criterion specifically checks "all members have empty deposits" rather than just "no recent activity," since a pool with real funds sitting quietly for 90 days is a very different case from one that was truly never funded, and archiving the former would hide a pool users might still care about.
4. Wire the cron job to set archived_at/archive_reason on matching pools, write an archive_log entry for each, and send a summary notification to each affected pool's admin, scheduled daily at 02:00 UTC via Vercel Cron.
5. Modify frontend/app/explore/page.tsx and the underlying /api/pools query to exclude archived pools by default, add the archived query param (default false), and add a "Show Archived" toggle that renders archived pools as grayed-out cards with an "Archived" badge when enabled.
6. Modify the My Groups page to split into "Active" and "Archived" tabs, with the Archived tab showing a compact list (name, type, completion date, final TVL, archival reason) rather than full pool cards, and build frontend/components/shared/archived-pool-card.tsx as that compact card with a "View History" button linking to the read-only detail view.
7. Modify the pool detail page so archived pools render fully read-only: no deposit/withdraw/pause buttons, an "Archived" banner explaining the specific reason, and the activity feed still visible but clearly marked as historical, confirming this by attempting each mutating action on an archived pool and asserting it's blocked at both the UI and API level (not just hidden buttons).
8. Implement PUT /api/pools/[id]/archive and PUT /api/pools/[id]/unarchive for manual admin control, both admin-only, with archive requiring a reason and unarchive reversing archived_at/archive_reason and logging the reversal in archive_log too.
9. Verify data preservation directly: confirm archived pools retain all Supabase data (metadata, members, activity) untouched, on-chain contract data is unaffected by any of this (it's purely an off-chain visibility layer), and historical data export still works for an archived pool.
10. Confirm no performance regression on Explore/My Groups by checking the default queries use an index-friendly archived_at IS NULL (or equivalent) filter rather than a full-table scan, and measure query time before/after on a dataset with a meaningful number of archived pools mixed in.

[isaacsamual994-lang]

Hi! I’d like to take this on. I can implement the archival flow end-to-end: Supabase migration and archive_log, the daily Vercel cron with the three archival criteria, admin archive/unarchive endpoints, archived filtering in Explore/My Groups, read-only archived pool detail views, and regression tests around false-positive archival and data preservation. I’ll keep the change scoped to this issue, verify the current test/build commands locally, and document the archival behavior and rollback path in the PR.

[olathedev]

Hello maintainer, i would love on this issue.