Feat/backup

[carnach]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
my-spliit-instance	Ready	Preview, Comment	Feb 1, 2026 9:35am

[Copilot]

Pull request overview

This pull request adds comprehensive backup and restore functionality for groups, along with S3 document cleanup capabilities and Vercel Analytics integration. The feature allows users to export full backups (as ZIP files with complete data), import from JSON exports (with limited data), restore backups, and delete groups with optional document cleanup.

Changes:

• Added backup export/import functionality with ZIP file support (full backup) and JSON import (limited format)
• Implemented group deletion with optional S3 document cleanup and document count display
• Added Vercel Analytics integration for usage tracking

Reviewed changes

Copilot reviewed 26 out of 27 changed files in this pull request and generated 24 comments.

Show a summary per file

File	Description
src/lib/backup.ts	Core backup logic for creating and restoring full group backups with documents and activities
src/lib/json-import.ts	JSON import logic for migrating groups from other Spliit instances (limited data support)
src/lib/api.ts	Added group deletion functions and document count queries; modified expense creation to use doc.id
src/app/groups/backup/import/route.ts	API route for analyzing and restoring ZIP backup files
src/app/groups/[groupId]/backup/export/route.ts	API route for exporting complete group backups as ZIP files
src/app/groups/json/import/route.ts	API route for analyzing and importing JSON exports
src/app/groups/[groupId]/data/delete/route.ts	API route for undoing last JSON import
src/app/api/groups/[groupId]/has-import-marker/route.ts	API route to check if group has imported data
src/app/groups/delete-group-actions.ts	Server actions for S3 document deletion (safely accesses env variables)
src/trpc/routers/groups/delete.procedure.ts	tRPC procedure for deleting groups with optional document cleanup
src/trpc/routers/groups/get-document-count.procedure.ts	tRPC procedure to get document count for a group
src/trpc/routers/groups/expenses/delete.procedure.ts	Modified to delete S3 documents when deleting expenses
src/components/restore-backup-button.tsx	UI component for restoring backups with version comparison
src/components/import-json-button.tsx	UI component for importing JSON exports with warnings
src/components/delete-group-dialog.tsx	Dialog for deleting groups with document deletion option
src/components/delete-data-button.tsx	Button to undo last import
src/app/groups/[groupId]/activity/activity-item.tsx	Modified to display import activities with JSON-parsed data
src/app/layout.tsx	Added Vercel Analytics component
package.json	Added @vercel/analytics and jszip dependencies
messages/en-US.json	Added translations for backup/import UI

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The comment at lines 71-73 indicates awareness that participants can't be deleted by creation time, but leaves them in the database. This creates data inconsistency where imported participants remain after "undoing" an import. These orphaned participants could:

1. Confuse users who expect a complete undo
2. Cause issues if the user tries to re-import with different participant IDs
3. Accumulate over multiple import/undo cycles

Consider implementing participant cleanup by: 1) Deleting participants that have no associated expenses after the expense cleanup, 2) Adding a createdAt field to the Participant model, or 3) Tracking imported participants in a separate table or using activity markers.

Suggested change

	// Delete participants - Note: Can't filter by createdAt as it doesn't exist
	// We'll keep participants to avoid breaking expense references
	// Alternatively, delete only participants not referenced by remaining expenses
	// Delete participants that are no longer referenced by any remaining expenses
	// This avoids leaving orphaned participants after undoing an import.
	await tx.participant.deleteMany({
	where: {
	groupId: groupId,
	// Only delete participants that have no associated expenses
	// (and no associated expense-paid-for entries, if such a relation exists).
	expenses: {
	none: {},
	},
	expensePaidFor: {
	none: {},
	},
	},
	})

[Copilot]

The deleteDocuments parameter is passed to the function but never used. Line 20 hardcodes false, which means documents will never be deleted from S3 even when deleteDocuments is true. This appears to be a logic error where the intention was to pass deleteDocuments instead of false.

The call should be: await deleteGroupWithDocuments(groupId, deleteDocuments ?? false) to respect the user's choice.

Suggested change

	await deleteGroupWithDocuments(groupId, false)
	await deleteGroupWithDocuments(groupId, deleteDocuments ?? false)

[Copilot]

The transaction timeout is set to 60 seconds with a maxWait of 20 seconds for large imports. However, given the sequential nature of the operations in restoreGroupFromJSON (see performance issue in json-import.ts), this timeout may not be sufficient for very large groups (e.g., 500+ expenses). The maxWait of 20 seconds might cause the transaction to fail before it even starts if there's database contention.

Consider either: 1) Optimizing the restore operations to use batch inserts, 2) Increasing the timeout further, or 3) Adding a progress indicator and allowing the operation to be performed outside a transaction with proper error handling and rollback capabilities.

[Copilot]

The JSON parsing is vulnerable to malicious or malformed JSON files that could cause a denial of service. There's no file size validation before calling file.text(), which means an attacker could upload a multi-gigabyte JSON file that would consume server memory. Additionally, JSON.parse() has no protection against deeply nested objects that could cause stack overflow.

Add file size validation (e.g., max 10MB for reasonable group exports) before parsing, and consider using a streaming JSON parser for large files or adding recursion depth limits.

[Copilot]

The backup restoration doesn't validate that categoryId references in expenses actually exist in the database. If a backup contains a categoryId that doesn't exist (or was deleted), the expense creation will fail with a foreign key constraint violation, causing the entire restore transaction to fail.

Consider either: 1) Pre-validate all category IDs and create missing categories from the backup data, 2) Use category information from the backup to recreate categories if they don't exist, or 3) Handle the foreign key error gracefully and default to categoryId: 0.

Suggested change

	await prisma.expense.create({
	data: {
	id: expense.id,
	groupId: group.id,
	expenseDate: new Date(expense.expenseDate),
	createdAt: new Date(expense.createdAt),
	title: expense.title,
	categoryId: expense.category?.id ?? 0,
	amount: expense.amount,
	originalAmount: expense.originalAmount,
	originalCurrency: expense.originalCurrency,
	conversionRate: expense.conversionRate ? new Prisma.Decimal(expense.conversionRate) : null,
	paidById: expense.paidById,
	isReimbursement: expense.isReimbursement,
	splitMode: expense.splitMode as any,
	notes: expense.notes,
	recurrenceRule: expense.recurrenceRule as any,
	},
	})
	const expenseData = {
	id: expense.id,
	groupId: group.id,
	expenseDate: new Date(expense.expenseDate),
	createdAt: new Date(expense.createdAt),
	title: expense.title,
	categoryId: expense.category?.id ?? 0,
	amount: expense.amount,
	originalAmount: expense.originalAmount,
	originalCurrency: expense.originalCurrency,
	conversionRate: expense.conversionRate ? new Prisma.Decimal(expense.conversionRate) : null,
	paidById: expense.paidById,
	isReimbursement: expense.isReimbursement,
	splitMode: expense.splitMode as any,
	notes: expense.notes,
	recurrenceRule: expense.recurrenceRule as any,
	}
	try {
	await prisma.expense.create({
	data: expenseData,
	})
	} catch (err: any) {
	// Handle potential foreign key constraint violations on categoryId
	if (err instanceof Prisma.PrismaClientKnownRequestError && err.code === 'P2003') {
	// Retry with a default/uncategorized categoryId
	await prisma.expense.create({
	data: {
	...expenseData,
	categoryId: 0,
	},
	})
	warnings.push(
	`Category not found for expense "${expense.title}", defaulted categoryId to 0 during restore.`,
	)
	} else {
	throw err
	}
	}

[Copilot]

These API routes lack any authentication or authorization checks. Anyone who knows a groupId can restore a backup, import JSON data, or delete all imported data for that group. This is a critical security vulnerability as it allows unauthorized access to modify or destroy group data.

At minimum, implement validation that the requester has permission to modify the group (e.g., by checking if they've recently accessed it, or by implementing a proper authentication system). Consider requiring a confirmation token or password for destructive operations.

[Copilot]

This route allows anyone to delete all imported data from a group without authentication or authorization. This is a critical security vulnerability that could allow malicious actors to destroy data.

Implement authentication/authorization checks to ensure the requester has permission to delete data from the group.

[Copilot]

Using native alert() for displaying warnings is not user-friendly and breaks the modern UI/UX pattern of the application. The alert is modal and blocks the UI, and on some mobile browsers may not display properly. Additionally, the warnings could contain long lists of missing documents that won't fit well in an alert dialog.

Consider using a toast notification, dialog component, or dedicated warnings section in the UI to display these messages in a more user-friendly way that matches the rest of the application's design.

[Copilot]

The JSON parsing of activity.data (line 63) lacks proper error handling and validation. While there's a try-catch block, it silently fails without logging, making it difficult to debug issues. Additionally, there's no validation that the parsed object has the expected structure before accessing its properties.

Consider adding validation for the parsed object structure and logging parse errors in development mode to help with debugging.

Suggested change

	const parsed = JSON.parse(activity.data) as { title?: string; importDate?: string }
	if (typeof parsed.title === 'string') expenseTitle = parsed.title
	if (typeof parsed.importDate === 'string') importDate = parsed.importDate
	} catch {
	const parsed = JSON.parse(activity.data)
	if (parsed && typeof parsed === 'object') {
	const { title, importDate: parsedImportDate } = parsed as {
	title?: unknown
	importDate?: unknown
	}
	if (typeof title === 'string') expenseTitle = title
	if (typeof parsedImportDate === 'string') importDate = parsedImportDate
	}
	} catch (error) {
	if (process.env.NODE_ENV !== 'production') {
	// eslint-disable-next-line no-console
	console.error('Failed to parse activity.data JSON', { error, data: activity.data })
	}

[Copilot]

Unused variable existingExpenseIds.

Suggested change

const existingExpenseIds = new Set(existingGroup.expenses.map(e => e.id))

[carnach]

@copilot open a new pull request to apply changes based on the comments in this thread

[Copilot]

@carnach I've opened a new pull request, #15, to work on those changes. Once the pull request is ready, I'll request review from you.