Ride Archival

The platform automatically archives completed rides at midnight after their scheduled end time, moving them out of Firestore and into long-term storage to reduce costs while keeping them accessible through Ride History.

Who Can Do This

This is a system process — no user triggers it. It runs automatically once a ride's end time has passed.

How It Works

  1. A ride's status changes from on-going to completed once its scheduled end time has passed.
  2. Participants stop seeing the ride in the main interface 1 hour after the end time.
  3. The ride creator and admins continue to see the ride in the main interface until archival completes.
  4. At midnight after the ride's end time, the archival process runs:
  5. The ride document and participant list are written to Google Cloud Storage as a JSON file.
  6. Shared location data and audio session metadata are permanently deleted.
  7. The ride document is removed from Firestore.
  8. The ride becomes accessible through Ride History immediately once its end time passes — not only after archival. During the window between step 2 and step 4, the ride is no longer visible in the main interface but is still in Firestore. Ride History reads from Firestore first, so the ride is available as a completed ride throughout this window with no gap.

Rules

  • For completed rides, archival triggers at midnight after the ride's end time.
  • For deleted rides (soft-deleted by the creator), archival triggers at the next midnight after the deletion date — not after the ride's originally scheduled end time. This applies to deleted drafts, upcoming, and on-going rides alike. The cap slot is freed immediately on deletion; archival only handles the document cleanup. A deleted ride can be recovered before this midnight archival runs — see Undelete a Ride.
  • The ride document, participants, and routes/breakpoints are preserved. Shared locations and audio session metadata are deleted and not recoverable.
  • Retention duration for archived JSON files in Cloud Storage is governed by the Data Retention Policy.
  • The transition is seamless to users — the Ride History screen reads from archived storage with no visible difference.
  • If archival fails, the platform retries up to 5 times. If all retries fail, an alert is raised for manual intervention. The ride remains visible to the creator and admins in the main interface until the failure is resolved and the process is retried manually.
  • No notification is sent to the creator or participants when a ride is archived.

Sub-documents: Archive vs Delete

Sub-document Action
Ride document (root) Archive to GCS
Participants Archive to GCS
Routes / Breakpoints Archive to GCS
Block list Archive to GCS
Pending RSVPs Delete
Shared Locations Delete
Audio session metadata Delete

Failure Cases

  • Archival fails after 5 retries — the ride remains in Firestore and stays visible to the creator and admins in the main interface. An alert is raised for manual investigation. Once the cause is resolved, the archival can be retried manually via Temporal.
  • End time not yet passed — archival depends on the ride status being completed (end time passed). If the status update process has not run, archival will not trigger.

Status: partially-live. The Temporal worker for ride status transitions (upcoming → on-going → completed) is complete. The archival step that moves completed rides from Firestore to Cloud Storage is not yet confirmed as built. Ride History depends on archival being live.